t contribution value as the designated client. If the server cannot find any client having the file as the designated client, it will transmit the file by itself, thereby adding itself as the transmitting computer (for simplicity, in this context, we call it ‘designated client’ as well) into the third dimension list of the file request AFRDT. The choosing of the designated client may also combine with some customized parameters, such as its priority. After the disposal, the server sends the disposed file request to the request client.
The request client receives the disposed file request, distilling related information from it, especially on which clients where it can find the needed files from the designated clients in the AFRDT of the file request. Thereafter, the client sends a file transmitting request 515 to the specific port of each designated client. The designated client 531 receives the file transmission request and initiates the transmission 305 if it has the file. Optionally, it can decide by itself whether to start the transmission or not according to its current performance condition. The client uses the local memory (RamDisk) to keep the downloaded files, or it can use other virtual disk techniques to provide the storage. After the transmission of a file is finished, the request client will check whether all the files belonging to a specific application are available. If it does, the application is loaded by the request client 516. Meanwhile, the request client sends a Transmission Finished message to the server to indicate from which client it has downloaded a specified file. After receiving the message, the server will add the request client to the corresponding third dimension list of the server AFRDT and update its contribution value in the contribution field of the client list 525.
If the request client cannot complete the file transmission (due to some factors such as “cannot setup the TCP connection to the designated client”, or some file read/write errors occurred) the client sends a redirection request to the server 517 to indicate which client was unable accomplish a file transmission. After receiving the redirection request, the server re-selects another designated client for the request client 524. Optionally, at the same time, the server deletes the previous designated client from the third dimension list of the server AFRDT corresponding to the file, for it may not be able to provide that file any more. The request client receives from the server the re-designated client and completes the transmission of the related file over again.
If all initial applications in the local client AFRDT of a request client have already been started (meaning the client has finished its booting procedure) it will send a booting success message to the server 518. The server updates the status of the request client as ‘booted’ in the client list 526.
As far as the downloaded copies of the initial application files are concerned, if they are modified or deleted locally during the running of the client, they are apparently not the desired initial application file by other clients. When that happens, the client sends a File Modification message to notify the server they are not available in future. After receiving the notification message, the server deletes that client from the third dimension list of the server AFRDT corresponding to the file.
A problem can occur if, in the early running phrase of the whole system, a situation exists where there are many clients that want to boot at the same time. As an improvement, if for the 6 time, the server has received more than a requests, and there are less than P clients having already been started, it then puts a portion (e.g. ½) of the requests into the waiting queue. The step may also combine with clients' priority. The parameter δ is of the same definition as above. The parameter σ can take a half of the theoretical maximum client-loading number of the server (MLC) as its value, or it can take ⅔ of the measured maximum client-loading number of the server (PMLC) as its v