uests in the processing queue in a round-robin manner, having no strict mechanism, while the file requests in the waiting queue have to be delayed by the parameter δ for shifting into the processing queue. The value of δ can be set according to users' in-field need or it can be set as an experience value. Normally δε [1-60] second, or 1-5 times of the measured average time for the server disposing a single file request.
To put a file request into which queue mainly depends on the server's performance condition at that time, which may be embodied by some parameters, such as the CPU utility ratio Pλ, the memory utility ratio Mλ, the virtual memory utilization ratio Gλ, the traffic to bandwidth ratio P/T, or an output value of a function that takes these factors as its input parameters. For example, supposing the performance function is Φ=Max(Pλ, Mλ, Gλ, P/T), where the threshold can be set as γε(0.8, 0.9). Therefore, when scheduling a newly-received file request, if Φ≧γ, the request is put into the waiting queue. If Φ<γ, then the request is put into the processing queue. Optionally, if the file request is of low priority, it may be put into the waiting queue directly, bypassing the server performance based decision-making.
When disposing a file request, the server knows what files the client is requesting according to the AFRDT table included in the file request. Then, for each file in it, the server searches it in its own AFRDT, choosing out one client which is stored in that file as the target transmitting computer (namely, the designated client), and adds it to the third dimension of the file request AFRDT 523.
The server can adopt among varied policies for choosing a designated client from its own AFRDT, which could be random, first match, LRU, or some priority based ones. In addition, in view of fairness, a type of policy based on the client's contribution can be adopted as follows. Based on the contribution value in the client list maintained on the server, the server selects out the client that has the lowest 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 redirec