The Client

PHP is a versatile language; normally it operates in conjunction with a Web server in order to generate Web pages. However, it can also be constructed as a regular system script interpreter, and with its large collection of provided libraries it is more than capable of carrying out background tasks on the Web server computer.

The client program for the communication system is written in the PHP language, but formatted to run as a normal operating system process. The enormous benefit of using the same language as the Web application is that program code can be shared between the two, often using the same code files simultaneously. Any changes made to the way system objects work, for example, requests and jobs, are immediately available to both the Web application and the communications software client. Regular boilerplate code

such as logging functions and database access do not need to be rewritten. In this way, background maintenance scripts can be constructed very quickly to perform complicated tasks, simply by pulling in and reusing code already constructed for the Web application. Alternative languages for implementing maintenance programs are plentiful, examples include C (Kernighan & Ritchie 1988), Perl (Perl.org n.d.) and Python (Python Software Foundation n.d.), but none present such significant benefits that would outweigh the enormous advantage of using the same language as the Web application.

The client is invoked by the operating system every five minutes. It is internally split into different task modules which perform the various functions required of the communications system. When invoked, the program iterates through the task modules in an order specifically designed to maximise the efficiency of the job allocation, transfer, cancellation and deallocation routines.

Figure 20: Work flow of job control client

Start

Retrieve information about robot-modified jobs

Process any instructions to hold jobs

Process any instructions to cancel jobs

De-allocate any completed jobs from the robot

Allocate new active jobs based on pool of requests

Send any new active jobs to the robot Any errors?

Any fatal errors? Any fatal errors? Any fatal errors?

Any fatal errors? Wait five minutes

Any fatal errors?

Stop yes yes yes yes yes yes no no no no no no

After establishing a network connection to the server at the robot, the client software first requests a list of modified jobs. In this context, a modified job is one which the robot has examined and changed in some way. The telescope robot modifies a job record when the scheduling score has been calculated for the job for the first time, when a job begins to be executed on the telescope and when a job completes (successfully or otherwise). All the client does with the data at this point is record the new job status codes in the active jobs table in the local database. This operation is very fast, since all the robot has to reply with is a collection of job identification numbers and their new status codes. This is the first communication to take place in the sequence in order to ensure that the following task modules work with the most up-to-date data.

Secondly, the communications software processes hold instructions. These are generated by administrators of the system in cases where jobs should be removed from the pool at the robot and put into a hold state. This occurs during development of the robot control software and other times when administrators wish to interrupt the normal autonomous operation of the robot. The client software transmits one hold instruction for each job which should be held – for each job that the server finds in a new or waiting state in its job pool, it removes the job from the pool and replies to confirm the job's removal. The server refuses to delete jobs from its database when they are already complete, or are currently being serviced on the telescope. Hold instructions are processed after the stage which downloads the list of modified jobs from the robot, to minimise the possibility of this ever happening. Normally these two operations would be performed with little delay in-between, making it unlikely that a hold instruction could exist for a job already completed or in progress.

Thirdly, the system processes cancel instructions. These exist when a user decides they no longer require a requested observation, or do not wish to wait any longer for it.

Cancel instructions work in the same manner as hold instructions, except that instead of local jobs being moved to the hold state they are set to a cancelled state and are removed from the list of active jobs permanently by converting them to complete jobs. Cancel instructions are processed after the list of modified jobs is downloaded and after hold instructions are processed – this is to ensure that the maximum possible number of jobs can be worked with locally, rather than contacting the robot. For example, if a job has already been completed or is currently in progress it cannot be cancelled, and if a job has already been held then no communication with the robot is necessary to cancel it because the job would not be in the robot database at that time.

Fourthly the system deallocates completed jobs. The earlier operation of retrieving a list of robot-modified jobs will have altered the relevant entries in the active jobs table of the Web interface database. Deallocating a job involves iterating through each of these modified jobs and for each one, downloading the resultant image if it was a successful job and acknowledging to the robot that the job has been received by the Web interface computer. The communications software at the robot removes the job from the job pool, while the software at the Web interface converts the active job entry in the database to a complete job entry. Users who had requested any of the deallocated jobs are sent an email notification about their newly completed jobs. At this point, if the request was a single-image request then it is marked as complete, and no further active jobs can be generated because of it. If the request is for multiple images in a series, and they have not all been taken, then it is marked with a special value to indicate to the allocator module that the request is not complete and should have more active jobs generated for it.

Fifthly, the allocator task module is executed, which examines the requests table for new and partially complete requests requiring more visits to the robot. For each of these

requests, a new active job object is created, however, before recording the new active job in the database the system scans the active jobs table for any identical waiting jobs. If an identical job exists then the newly created active job object is discarded and the request is linked to the existing active job. The existing job is updated to reflect the new number of requests depending on it. If no identical active job exists then the newly created one is recorded in the active jobs table and marked as new. It is this decision made by the software which solves the efficiency issue noted by the Oxenhope telescope team. Instead of taking several identical images of popular targets, one image for each user, the system groups identical requests and saves observing time by only imaging the target once, but returning that image to multiple users. While this could be seen as the robot cheating to save time, note that the only active jobs eligible to be grouped are ones that are already waiting in the job pool. Once a job has been marked as complete by the robot it cannot be grouped. This means that a user will always receive a new image from the telescope when they make a request, the system never uses images from its back-catalogue to service new requests. A user is free to view the back- catalogue of work at any time, and is indeed offered a selection of previous work at the time they submit a request, however, any new request will always result in a new observation image. It is important that the allocator is run after the de-allocator, since the de-allocator can mark some requests as needing reallocation, i.e. any multiple-image jobs requiring new active jobs.

Finally, any new, or newly modified active jobs are transferred to the robot by the final task module. The robot is allowed to refuse updates to existing jobs if the existing job is in progress or completed. In this case the client communications software leaves the active job to be updated by the next whole run of the software. This situation should be rare due to the operational ordering of the tasks in each run.