 the server AFRDT. Optionally, different personalized parameters like roles and corresponding priorities can be defined for clients according to their MAC address or IP address etc., so the server can designate different initial applications for different clients according to these parameters.
Until the client has received the OS kernel mirror, the cooperative client-booting method of the invention adopts similar process steps as the above-said MMNC embodiment. Concretely the process flow is as follows: 1) The Client begins its booting procedure after being powered on 511, executing the codes stored in local ROM 512; 2) the client establishes contact with the server by broadcasting to the network; 3) the server assigns an IP address for the client; 4) after acquiring the IP address, the client sends a request to the server for downloading the OS kernel mirror; 5) the server transmits an appropriate OS (e.g Linux) kernel mirror to the client by TFTP 521; 6) the client receives and loads the OS 513 and begins to run a TCP service to listen for any possible file transmission requests sent by other clients through a specific port; 7) meanwhile this request client sends a download request for downloading initial applications to the server 514; 8) the server receives 522 the download request (also called the file request) and then according to the MAC address of the client, decides its role and priority; 9) based on the priority, the server decides the importance of this file request 9a) if the file request has a low priority, it may be put into a waiting queue; 10) as for a file request, the server decides the client's initial applications corresponding to its role, recording these applications and related files into a new AFRDT data structure which is added to the file request; 11) the file request is then put into a suitable queue for processing.
The server maintains two queues of file requests: one is waiting queue, another is processing queue. Similar to the above-said embodiments, the server disposes the file requests 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 lowes