This collaborated computing system is modified from power server model. Its structure is illustrated in Figure 5.1. The major difference between the power server model and the collaborated computing system is the role of coordinator. In the
collaborated computing system, coordinator only deals with finding the available servers from the web. Moreover, the small programs in the collaborated computing system are executed by the Internet Explorer.
Figure 5. 1.Structure of collaborated computing system.
The collaborated computing system works as follow:
z Step 1: while server is idle, it passes its’ IP address to the coordinator.
Therefore, the coordinator can find available server on the Internet.
z Step 2: the coordinator conveys the IP address to client. By this way, the client realizes which server it can arrange sub-task to.
z Step 3: the client dispatches sub-task to the server.
z Step 4: After computing, this server delivers the result back to the client.
The design details of each role, client, servers, and coordinator, are described below.
5.2.1 Client specification
The client is not involved in the actual computation. It dispatches the sub-tasks and collects the sub-results. The tasks of the client include:
z Allows available server to connect.
z Arranges sub-task to servers;
z Maintains the database of the job progress;
z Gathers and stores the sub-result;
z Generates the final result; and z Validates the result.
In client part, error can not be tolerated. Therefore, the algorithm of job dispatch and database must be implemented carefully. Database is designed for following propose:
z Stores the filter for examination;
z Lists the available servers;
z Records the project progress; and z Collects the result.
There are 76177 sets of filter bank selection in the database. During the computation, the sub-tasks are arranged based on the initial setting, which are 250 sets of filters. Therefore, the number of total sub-tasks is 305. After all the sub-tasks are done, the results are collected and reported automatically.
Figure 5. 2. An example of the control panel in client side.
One control panel, shown as Figure 5.2, is provided. All the information will be presented in the center of the panel, including the connection between client and servers, and progress of the project. Moreover, in this panel, the drop down menu of tool includes three tools, which are Import Filter, Generate Corr, and Compare Corr.
The functionalities of those tools are listed below:
z Import Filter: as mentioned, in this project, there are 76177 sets of filter banks used for analyzing the robustness of digital watermarking. Therefore, those filter banks need to be imported into the database.
z Generate Corr: after computation is completed, the final results must be integrated into two text files. The first file was called corr1.txt. This is the result of the correlation between the original watermark and the watermark, which was extracted from non-tempered digital image. The second file was
called corr2.txt. This is the result of the correlation between the original watermark and the watermark, which was extracted from tempered digital image.
The tempered digital image was attacked by JPEG 2000.
z Compare Corr: this tool is just for validating the final result through comparing to the original result, which was generated by a single PC.
5.2.2 Server specification
Servers are in charge of the computation. Following are the tasks of the servers:
z Sends a request to coordinator;
z Receives the sub-task;
z Computes the result; and z Conveys the result to client.
For accomplishing those tasks, three small programs must be installed. The details of these programs are as following:
z The trigger program (P2P testing program): this program was implemented by Microsoft .Net. Therefore, servers must have installed the Microsoft .Net Framework 1.1. This program aims to trigger the computation by sending a request to the coordinator. There are three conditions to be fulfilled before starting the trigger, 1) Tomcat is running, 2) the process idle time is upon 70%, and 3) the last process has finished for 3 seconds (waiting time). The process idle time and the waiting time can be changed by the program, which is shown as Figure 5.3.
Figure 5. 3. An example of the trigger.
z Correlation program: for analyzing the robustness of digital watermark. The correlation between watermarks will be created by using the correlation program.
z Servlet: it is responsible for communication between client and server. The sub-tasks will be received as object, the correlation program will be invoked, and the result will be sent by this Servlet.
Figure 5. 4. An example of screen shot of server.
Considering the security in servers, no data will be stored except the programs, which were mentioned above. The server program was run as shown in Figure 5.4.
In server part, the difference between collaborated computing system and the power server model is the way of execution. In power server model, program was running as a screensaver. In this presented collaborated computing system, program was running in Internet Explorer. However, servers can decide how to share the CPU computing power.
5.2.3 Coordinator specification
In this collaborated computing system, the main goal of coordinator in the collaborated computing system is to discover the available servers on the web.
Therefore, coordinator is only involved in three tasks.
z Allows servers to register;
z Maintains the database of servers’ information; and z Passes the IP addresses of servers to the client.
The database is only responsible for recording the information of servers.
Moreover, no panel tool is provided in coordinator part.
Further, One Servlet, which was placed in the coordinator, deals with the communication between servers and client.
5.2.4 The algorithm of job dispatch
Client computer is responsible to the job dispatch. In this experiment, the job dispatch algorithm is described below and the flow chart is in Figure 5.5:
task_size = 1000
Function dispatch NewJob if (job_list == empty)
Function dispatch task(i) task(i).time = current transit the task(i) EXIT
End Function
Figure 5. 5. The flow sheet of job dispatching.
The algorithm for after receiving the sub-results from servers is presented as follow and the flow chart is in Figure 5.6:
receive result(i) find task(i) task(i).status = 1
Figure 5. 6. The flow sheet of receiving the sub-results.