val of t, goes to P2.
Else If the SNCS has received any contesting signal from other SNCS, it will delay for a time interval which is calculated by the Binary Exponential Backoff Algorithm as R*T*2ˆN, where R is a random number, T is the last calculated delay time (its initial delay is 2t-5t), and N is the number of calls of the algorithm. If the heart-beating signal is received during the delay, it will consider itself as a SNCS and goes to P2. Otherwise goes to P1;
In addition, if at any moment a MNCS receives a heart-beating signal from another MNCS (this may happen when the topology of networks is changed, resulting in that more than one MNCS appears in the same network), the cluster relation in this case should be adjusted dynamically as follows:
The MNCS which receives the heart-beating signal will send in an end-to-end manner the collision indication signal to the source MNCS of that heart-beating signal, which includes the content of its BMRT and SNCS list;
If a MNCS A receives a collision indication signal from another MNCS B, then A will compare the number of its SNCS with that of B's. If A has no less SNCS than B does, A will insert B into its own SNCS list, and non-redundantly insert the contents of B's BMRT and SNCS into its own. A collision ACK signal will then be sent to B. B is then turned into SNCS and is sent a collision indication signal. However, if A has less SNCS than B does, A will send a collision indication signal to B, consider itself as a SNCS, stop broadcasting the heart-beating signal to the network and initialize the BMRT and the SNCS list.
Clients can use the services provided transparently by server clusters. As for the server cluster, the processing of the clients requests for services is a little different from that of the single-server system. The server cluster provides the booting service to a client after the client being powered on as follows:
The client broadcasts a DHCP message to the network;
After receiving the message, the SNCS will do nothing if the client could not be found in its Subscriber list. If the client does exist in the list, services (IP allocation, OS kernel downloading, file transmission, etc.) will be provided by the server.
After MNCS receiving the message, if the client could not be found in its BMRT list, MNCS will bind the client to a server and add it to the related lists of that server (can be one of the SNCS or the MNCS) according to different policies (e.g. Finding a server that has the least load based on servers' performance parameters or Round-Robin.). If the target server for binding is a SNCS, the MNCS will notify it about the binding event. The target server (namely, the binding server) will then add the client to its Subscriber list, and provide the client with services.
After loading the downloaded OS kernel mirror and initial application, the client will broadcast to the network again. Its binding server will return a response so that the client could learn to which server it has been bound. Thus the booting process of the client is accomplished.
Henceforth, the client could send requests to its binding server for services such as customization on demand, or application downloading.
As for another embodiment, the client does not need to know its binding server at all. The client could broadcast the related requests to the network when needed. After receiving the request, the server will make a judgment of whether the client is an affiliated one or not: if YES, service will be provided; if NOT, the request will be ignored.
If for some reason the topology of the network has changed, or the binding server of a client is down, which will prevent the client getting requested services from the server, then the client will be rebooted manually or automatically after the ‘N/A’ situation of the server is detected. Since the cluster relations will be automatically updated after the same ‘N/A’ situation of the SNCS being detected by the MNCS, the client will then be bound to another SNCS after being rebooted.
As still another embodiment, servers could manua