The solution suggested rests on the division of the program in three subroutines :
This organization will make it possible to the user to use all the machines available in a transparent way, without worrying to distribute its tasks.
The customer part consists of an application made up of a common library of functionalities, and two distinct interfaces:
The choice of the graphic library was made on QT because this one can be used on a significant number of platforms (Windows, Unix) and has a layer of functionalities independent of the platform: communication by sockets, access to the files. We can also find there interesting components (engine of returned HTML for example).
Moreover this library is usable under licence GPL.
The role of the client will be to make it possible to the user to subject his treatment, its task, with the system. This task is characterized by:
This task will be transmitted from the client to the controller.
The controller is the most significant part of the system. It plays the role of intermediary between the client and the available agents for calculations. This application does not have a graphic interface and will be carried out only in command line under Unix (Solaris server particularly).
For this application, we will use the library Netscape Portable Runtime (NSPR). This library makes it possible to have a library of programming multi-platforms for the management of the network and the files.
The controller carries out an identification of the clients wishing to connect to it. The list of the authorized clients is stored in a file. The policy of access authorization of the clients will be based on the address network of its (possibility of prohibiting or of authorizing all under network in the file of configuration).
In a first evoked solution, the controller had to receive from the client the descriptor of task, the data to be treated as well as the binaries. The controller was charged to find an agent responsible for the task, and to send the data to him to be treated.
However, this solution, although possible, did not satisfy the responsible teacher completely. Indeed, the sending of the data to carry out the task as well as the return result, always overloaded the network.
A second solution obliged the controller to go to seek the data and the binaries on the server of storage, and to transmit them to the agent. Once the finished task, the agent returned the result to the controller. This solution joined the preceding one partly, and was still not satisfactory for the same reason.
The adopted solution was the sending of the descriptor of task to the agent, which must deal with the recovery of the data, of the execution of the task, and the storage of the result; The workload on the controller being thus reduced.
A task is indivisible and is carried out entirely by only one agent.
The agent will firstly seek datas to be treated on the file system in network (via NFS), and must thus manage the execution of this task. To have access to the file system in network, the agent must beforehand have been configured. moreover, th agent owes to send punctually informations to the controller concerning the course of the task (load CPU, size of the treated data...). When a task is finished, the agent specifies it to the controller, who will send the report of the execution by electronic mail. A checking of the data will be carried out in order to avoid creating doubled blooms of data. This checking will be carried out compared to the size and the creation date of the task.
The agent will locally create a repertory by task, in order to store the various datas and files. It will be then charged to add on the file system the result and the course of the execution of the task.
Finally, following the example controller, the agent will carry out a checking of the IP of the machine contacting it. This will make it possible to prevent that any machine comes to subject tasks to the agents whereas it is not authorized.