CN86107645A - Transmit the method for resource information in the computer network - Google Patents

Abstract

A method of transferring resource information among computers in a computer network in a fully distributed manner. Every time when the user computer is connected to the network, a request message is sent from the user computer to one or several predetermined server computers, and each predetermined server computer first determines whether it can be used as a resource of the user computer when responding to the request message. Whether the server computer is available or not, the server sends a positive response message or a negative response message to the user computer respectively. When a server is available as a resource for one or several user computers, it sends a requisition message to one or several standby user computers.

Description

Method for transmitting resource information in computer network

The present invention relates generally to computer networks and, more particularly, to a method of distributing resource information to network computers to form a distributed database that enables sharing of computer resources among the computers in such networks for distributed processing.

Much work has been done to implement distributed processing in computer networks. Distributed processing averages jobs between those computers that have generated congestion and those computers that have remaining capacity, thereby improving network efficiency. For example, a user may transfer some time-consuming jobs, such as text formatting, floating point arithmetic, etc., from a home computer to a computer specifically adapted for such jobs.

In a network that allows shared resources, it is common for each computer to intend for other computers in the network to be able to serve as the resources of that computer.

In some systems, centralized resource name service work is done on one computer in the network alone. A computer sends a request to the computer to find out which computer can share resources with it. If these individual computers fail, network resource sharing and resource name servicing is interrupted. Another disadvantage of this centralized approach is that an additional visit to the central computer is required before processing can continue. For these and other reasons, some networks employ distributed name services. The LOCUS system described by Popek et al in "network transparent and reliability distributed System" (ACM-SIGOPS layer 8 operating System conference report, 12. 1981, P.169-177) is an example of a virtual centralized name server. It enables a computer network to emulate a virtual computer. This technique unnecessarily sacrifices the autonomy of the various computers in the network to a large extent.

Another centralized name server is the "CSNET name server" by M.Solowion et al (Netherlands publishing company; computer network 6 (1982), P.161-172). However, in this system, some of the problems of a centralized server are alleviated by temporarily storing a portion of the server information as it is received by each computer.

In "science and technology information station: a distributed system is described in the document "decentralized organization for locating designated objects" in the distributed environment (proceedings of the American computer society for office information systems, volume 1, No. 3, month 7 1983). Gertner and r.hindenberg introduced a partially distributed database name server in another ring network in the context of "wide area network repeat name server initialization".

The distributed name servers described above each include some very complex algorithms that adjust the decentralized databases to accommodate network changes. The problems that must be addressed include: how to do when a computer joins the network, how to ensure consistency of the repeated portions in the distributed database, how to know that a server has been put into operation, how to inform the user of this, how to do when a server is back to the networked state, and so on.

The U.S. patent 4,423,414 enterprise employs a broadcast scheme in the network to address some of the problems described above. A preparation user process that wants to execute a program issues a program-identifying message to the network at a remote location. Those computers that identify the program respond. The first responding computer is selected.

These problems are solved in accordance with the present invention by a method for transferring resource information between computers in a computer network. Each time a user computer is networked, a request message is sent from the user computer to one or more predetermined server computers. In response to the request message, each predetermined server computer determines whether the requested resource is made available to the user computer in that server computer. The server then sends a positive or negative response message to the user computer depending on the presence or absence of the requested resource on the server computer, respectively.

In addition, when the resources of a server computer are available to one or more user computers, the server computer sends an apply message to one or more alternate users.

A computer may revoke the availability of resources to one or several of the prospective users. This is achieved by: a stop solicitation message is sent to the relevant user computer. This approach, outlined above, is reliable because it implements a distributed resource name server, and because it allows temporary inconsistencies between the resource data of different computers, and may allow individual computers to fail. In the preferred embodiment disclosed, the resource that is available or unavailable is actually the central processing unit of the computer itself. For example, one computer may or may not be available for remote processing by another computer. However, the present invention is not limited thereto, and the resource may be anything, such as a device (printer, etc.), a file, and the like.

Each computer in the network contains a server database and a user database. In the server database, there is a number for each networked computer that is available at any time as a resource for that computer. The "permit" flag in each entry indicates whether the provisioning server is available at that time as the actual server for that computer. The "apply" flag in each entry in this database indicates whether the preparation server computer has notified this computer that it is available as its resource. Similarly, each network computer is provisioned with a credit in the user database, making it possible to have that computer become its server at all times. The "permit" flag in each subscriber database entry indicates whether the associated provisioned subscriber is now available as the actual subscriber. The "apply" flag in each entry indicates whether the computer has informed the subscribing user of the resources available to him.

The following is a typical method of making a computer a computing server, the computer issuing solicitation messages to all licensed network computers logged into a user database. In addition, the computer may also send solicitation messages to the selected subset of user funds. All computers receiving the solicitation message log the availability of the computing server in the relevant server entry in the local server database. When the server issues the solicitation message, a user computer may not be working and may be in a offline state. The computer issuing the solicitation message sets the "solicitation" flag in its user database regardless of the state of the user computer, and to avoid database inconsistency problems between the server and the user, the computer automatically issues a request message inquiring the availability status of all selected potential users in the server library while it is networked. Computers that are not currently available as servers send back a negative reply message to the request message. Otherwise, it returns a positive answer.

When the computer receives a stop solicitation message from a server, the computer resets the pertinent "solicitation" flag and removes the server from its active server registry.

If a server fails after issuing the solicitation message, the failure may be detected when the user computer enterprise uses the computing server as a resource. When this occurs, the user computer resets the relevant "apply" flag in the local server database. When the compute server resumes the networking state, it reissues the solicitation message.

Once the server sends the solicitation message to the user, the user may start a job, e.g., complete his or her remote processing on the server. This is done by a join message sent from the user to the server. When the connection is successful, a dedicated communication path is established between the user and the server. This communication path will remain the same until the user issues a "disconnect" command or the server issues a stop solicitation message to the user.

The communication between the user and the server is completed through a one-way communication channel. The receiving end of a channel on a computer is determined by a communication unit called a receive descriptor. The receive descriptor points to a queue holding incoming messages waiting to be processed. It is also coupled to one or a set of processes that interpret messages to the descriptor. The sender of the channel is determined by a communication unit called a send descriptor. Before sending a message to a server, a user first establishes a channel receiver for receiving a server response. The feature code of the receiving end of the channel is included in the message, so that the server can establish the corresponding sending end of the channel.

Fig. 1 and 2 illustrate the format of the user database and the server database in each networked computer. These databases located in each computer respectively determine which other computers the computer can act as a server to and which can act as a user to;

FIG. 3 is a process flow diagram illustrating the process of issuing solicitation messages to one computer when the other computer is acting as a server;

FIG. 4 is a program flow to be completed in response to solicitation of messages from other computers;

FIG. 5 is a process flow diagram illustrating the process of issuing a stop solicitation message to one computer when the other computer is acting as a server;

FIG. 6 is a process flow to be completed in response to a stop solicitation message from another computer;

FIG. 7 is a process flow executed by a computer when requesting modification of a solicitation flag from a local server database;

FIG. 8 is a program flow executed by a computer in response to a request message from another computer;

FIG. 9 is a program flow executed by a computer in response to a join command, through which a communication path is established between the computer and a distributor server process in each pre-provisioned server computer;

FIG. 10 is a program flow executed in response to a join message generated on another computer in accordance with the program of FIG. 9;

fig. 11 through 15 illustrate communication channel connections between two network computers, a user and a server, for various network communication protocols of the present invention, including solicitation message issuance, connection, request and remote processing.

In the preferred embodiment of the present invention, each network computer is controlled by a UNIX (UNIX is a trademark of the United states telex corporation) operating system, although the present invention is not limited thereto.

Each computer has a user computer database and a server computer database. The information in these databases is distributed throughout the network so that the database in each computer only stores information about that computer. Fig. 1 shows a user database 100. All other computers in the network for which this computer can act as a calculation server at different times are listed in the user database 100 of the computer. However, to enable the computer to act as a server for the provisioned users, a credit in the user database 100 is not sufficient. In addition, the server must issue solicitation messages to the pre-provisioned users stating that it is available, and the two computers must be "linked". The significance of these terms will be further appreciated in the following description.

In the user database, each pre-spare user has a unique account. As shown in fig. 1, an entry includes a user name 101, a password 104 used by the user for privacy, a receive descriptor 105 of the web server process within the provisioned user, and a set of such flags 106,108. The username is used to uniquely identify the computer in the network. Here, the reception descriptor 105 is actually an address that can be converted into a reception descriptor. Generally, the receive descriptor identifies a computer and a particular file on the computer to be linked to a given process. The receive descriptor 105 identifies a communication path to the web server process on the associated provisioning server computer and thus may be considered permanent information. It is always present, enabling the computer to communicate with the pre-provisioned user computer.

The flags of interest here are a "permit" flag 106 and a "apply" flag 108. The "permit" flag is set when the computer has served as a server for the network computer identified by the user network designation. By way of example, such licensing can be done under the control of a computer administrator. When this computer issues a solicitation message to a pre-provisioned user computer to be available as a server, the "solicitation" flag is set. The rest of the flags in the user database are not useful for understanding the present invention.

The server database 200 is shown in fig. 2. It is analogous to database 100 and lists all network computers that may be used as computer servers for this computer. One entry in the server database 200 includes the public network name 201 (e.g., EAGLE) of the provisioning server computer, the receive descriptor 210 of the network server process on the provisioning server computer (analogous to the receive descriptor 105 in the user database), the words used to store the receive descriptor of the remote process on the provisioning server computer (when it is known), 212, "permission" and "requisition" flags 206 and 208. These tokens have a meaning similar to the same name tokens in the user database. Under the control of a computer administrator, the "permit" flag of a computer is set, indicating that the computer is operating in its user database or server database.

Fig. 3 shows the program steps performed in this embodiment for a computer to announce availability as a resource to other network computers logged into its user database. However, prior to the description of FIG. 3, reference is preferably made to FIG. 11. FIG. 11 shows two network computers RAVEN and EAGLE. RAVEN and EAGLE include web servers 1100 and 1102, respectively. A network server is a program that receives messages from other network computers and processes them in an appropriate manner. For example, a web server may be the first contact on a computer used for email processing. In this case, the web server is used to, among other things, receive messages from other computers, establish a communication channel between the computers based on the solicitation message, initiate a remote processing server (service program for remote processing requests) based on the remote processing request, and establish a direct communication channel between the user computer and the remote processing server.

Each computer in the network is provided with a receive descriptor for each other network computer with which it can communicate. This receive descriptor is stored in user database 105 and server database 212, respectively. In FIG. 11, the receive descriptors correspond to rd1 for RAVEN and rd2 for EAGLE. Note that receive descriptors rd1 and rd2 are associated with the web servers 1100 and 1102 corresponding to RAVEN and EAGLE, respectively, via communication channels. If RAVEN wants to send a message to EAGLE, it does so: the receive descriptor rd2 is retrieved from an associated user database or server database. Similarly, EAGLE communicates with RAVEN using rd1 obtained from its user database or server database.

It can be seen with reference to figure 3 how solicitation messages are sent from a provisioning server to a provisioning subscriber. The reader is referred to fig. 12 at the same time as this description is made. When a request occurs by a computer administrator or a computer (e.g., EAGLE) is launched into the network, the process proceeds to the "apply" process 300 of fig. 3. Block 301 initializes the "apply" program to loop through all of the entries in the user database 100. After all the money processing is finished, the program exits at 302. For the user database entry currently being processed (e.g., RAVEN), the "permit" flag in the entry is checked by block 304 to determine whether the computer is currently available as the server for the provisioned user, keeping in mind that the "permit" flag is set or reset under the control of the computer administrator. If the "permit" flag is reset, this entry is ignored and the program loops to the next entry in the database. If this flag is set, then an advisory message is created at loop block 306 that includes the name of the advisory computer. Block 306 then opens an EAGLE send descriptor Sd1 and sends the solicitation message to the RAVEN's web server 1100 using Sd 1. It uses the receive descriptor rd1 to send the solicitation message to the RAVEN via the tunnel in the network. Block 308 sets the "apply" flag in the RAVEN entry in the user database of EAGLE. Thus, for this provisioning server (EAGLE), it has informed this provisioning user (RAVEN) that the local machine is already available as a resource. The process then repeats for other entries in the EAGLE user database.

In response to the solicitation message, a "solicitation" flag 208 is set in the server database of the pre-provisioned user, as will be further described below in conjunction with fig. 4. Note that no reply message is required, nor is the soliciting computer expected to obtain a reply message from the pre-provisioned user in response to the solicitation message. According to the invention, the levying computer does not need to adopt special precautionary measures to ensure that the server database of the pre-prepared user is properly adjusted. If the pre-provisioned user is off-line, the server database of the user computer will be adjusted by the request message at a later time when it is re-networked.

The solicitation message may be sent to only one computer in the network when needed, rather than all licensed computers in the user database. In this case, the "solicitation" program in fig. 3 enters the solicitation message as a pre-populated user input parameter directly from block 304. This purpose is not shown in fig. 3 for simplicity.

Figure 4 shows the program steps performed by the pre-provisioned user computer in response to the solicitation message. Solicitation messages are received at the pre-provisioned subscriber (RAVEN) via rd1 and sent to the web server 1100. The web server 1100 invokes the receive call subroutine 400 shown in figure 4. Block 401 uses the name of the server in the solicitation message to find the relevant entry in the computer server database. If the credit is not found, the solicitation message is not considered. Block 402 checks whether the "permit" flag is set for this server. If the flag is not set, the computer does not intend to use the server concerned, and thus, this "receive requisition" 400 subroutine ends. If the "permit" flag is set, block 404 sets a "apply" flag in the entry to record the availability of the server.

Fig. 5 shows the flow of a "stop call" routine 500. This procedure is performed on the server computer to make this computer no longer serve as a server. In our exemplary embodiment, this is done in accordance with a command from a computer administrator. Block 501 initializes a loop program to allow all of the entries in the computer user database to be processed. When all the items have been processed, the loop exits at 502. When the first entry is found in the user database, block 504 determines whether the "apply" flag has been set for the pertinent pre-provisioned users in the user database of the server computer. If it is not set, the item is omitted and the next item is processed. Otherwise, block 506 generates a stop solicitation message that includes the computer's name and sends it to the user's computer using the receive descriptor rd1 in the user database. The program does not wait or request that the user receive a reply signal to the message. Finally, block 508 resets the "apply" flag in the database entry, ending the process for this entry. The loop then repeats the process for other items in the user database. If for any reason the stop solicitation message is not received by the user computer, this will be handled later when the user computer makes a request or sends a remote processing request to the computer. In the latter case, the user computer requests a failure, resulting in a reset of the "apply" flag for that computer.

Also as in the case of the release of the levy message, the "stop levy" program may send the stop levy message to only one user computer if it enters the block 504 and has the user computer name as an input parameter.

Figure 6 shows the program steps performed by the computer upon receipt of a stop solicitation message. Block 601 uses the server name in the stop solicitation message to find the relevant entry from its server database. Of course, if this entry is not found in the database, the message is disregarded. Otherwise, the "apply" flag in the relevant server database entry is reset at block 602.

When the computer is brought back on line after being stopped or disconnected, the server database may have failed. For example, when a computer is off-line, there may be one or more network computers that solicit or stop solicitation messages from the computer, none of which are received. The program of fig. 7 sends a request message to all its pre-provisioning servers to adjust its server database. In this exemplary embodiment, the "request" procedure 700 is performed when the computer is networked or otherwise requested by a computer administrator. Block 701 initializes a loop program to enable it to process all entries in the server database of the computer. For the first entry, a determination is made by block 702 as to whether the associated server computer is likely to be a server based on the status of the "permit" flag. Bearing in mind that it is up to the computer administrator to decide whether a pre-provisioned server is permitted to become a server at any time. If the provisioning computer is not licensed, then the loop continues at block 701 with the next entry without regard to that entry. Otherwise, a request message is created for the provisioning server at block 704. Referring to fig. 13 (assuming RAVEN is the computer that sets up the request message), the program opens a receive descriptor rd4 to be used by the provisioning server and sends a response message back to the request message. The request message including rd4 is sent to a provisioning server (e.g., EAGLE) and the received descriptor rd2 of the word 210 in the server database is used to access the network server of the provisioning server computer. Block 706 waits a predetermined period of time long enough to receive a response message from the pre-provisioning server. The technique of creating such wait-loops is well known and varies from system to system. Block 708 is performed when a response is received, or a predetermined period of time has elapsed, whichever occurs first. Block 708 determines the outcome of the request message. If the server computer does not respond, or the response is answered "no" (indicating that it cannot serve as the server for this computer), then the associated "apply" flag is reset, via block 701. Otherwise, block 712 sets the flag for credit, recording the availability of the server computer. In either case, the loop program continues to process other items in the server database.

The "accept request" routine 800 of FIG. 8 shows the program steps performed by one computer in response to a request message from another computer. This response is relatively simple. The requesting computer's name is obtained from the received message and the "apply" flag in the relevant entry in the user database is interpreted by block 801. If the flag is set, indicating that the computer is available as a server for the requesting computer, block 802 generates and sends an affirmative response message to the computer. Otherwise, block 804 generates and sends a negative response message. This response message is sent back to the RAVEN, in this example, by opening a send descriptor (e.g., Sd 3) and sending the message to the receive descriptor (e.g., rd 4) received in the request message.

The "join" routine 900 of FIG. 9 is performed by a computer at the request of a computer administrator. The "attach" routine establishes a communication path to the remote processing server for each network computer registered within the server data with the "apply" flag set. This communication channel is used to transmit subsequent remote processing requests to the computer. Fig. 14 further illustrates how this is done, assuming here that RAVEN is the computer that performs the "join" procedure and EAGLE is a network computer in the RAVEN server database. Block 901 in fig. 9 initializes the loop program so that it can process all entries in the RAVEN server database. The "enlisting" flag for the first computer in the database is interpreted by block 902. If the flag is not set, then this entry is disregarded and the next entry is processed. If the flag is set and the computer is set as EAGLE, block 904 opens a receive descriptor (e.g., rd 4), and creates and sends a join message to EAGLE that includes the password and rd 4. Referring to fig. 14, the join message is sent to the send descriptor rd2 obtained from the word 210 in the server database to access the web server in the EAGLE. Block 906 waits for an EAGLE response in the usual manner.

FIG. 10 illustrates a "receive join" procedure performed when the EAGLE responds to the join message. The block 1001 interprets the "apply" flag 108 in the user database within the entry corresponding to RAVEN. If it is not set, indicating that EAGLE is not now available as a server for the RAVEN, a negative reply message is returned at block 1002. This response is sent through the receive descriptor rd4 in the original join message, as shown in FIG. 14. If the EAGLE has become a server of the RAVEN, the password contained in the message from the RAVEN is compared to the password in the word 102 in the EAGLE user database at block 1004 to verify that the join message is not from an impostor user. If the passwords do not match, a negative response is returned at block 1002. Otherwise, block 1004 opens another receive descriptor (e.g., rd 3) and sends a positive response message containing rd3 to RAVEN through rd 4. As shown in fig. 14, the receive descriptor rd3 provides a communication channel to the remote processing server in the EAGLE.

Returning again to the "join" routine of FIG. 9, block 908 determines whether the response from the EAGLE is positive or negative, or no response after a predetermined period of time. If a negative or no response is received, the server (EAGLE) is disregarded and processing continues at block 901 for the next entry in the server database. If a positive response is received from the RAVEN, block 910 retains the receive descriptor in the RAVEN server database in the entry word 212 corresponding to the EAGLE. Processing continues at block 901. Later, when the RAVEN receives a request from the user, or is requested by the process of sending a remote processing request message to the EAGLE, the rd3 in the RAVEN server database corresponding to the entry of the EAGLE is used to communicate directly with the remote processing server 1104 in the EAGLE. This is illustrated in fig. 15, where the RAVEN arbitration process 1500 opens a send descriptor Sd4 and sends a remote processing message to the remote processing server of EAGLE (mentioned in the above-mentioned co-pending patent).

In light of the foregoing, it will be apparent that certain modifications may be made in the invention. For example, a computer may specify in an solicitation message a time limit for which it can be used by a user as a server. Illustrating to the user the available time limit of the server may ensure time synchronization between the server and the user. Thus, while the user's view is different from the server for the absolute time available to the server, the view of both for absolute time is consistent with respect to the local clock. The suspension procedure in the pre-provisioning server may send a stop solicitation message to the user when a specified time limit is reached.

It will be understood that the above-described arrangements are only illustrative of the application of the principles of the present invention, and that other arrangements may be devised by those skilled in the art without departing from the spirit and scope of the present invention.

Claims (18)

1. A method for transmitting resource information between computers in a computer network, the operation steps comprising: for each computer, Publish the availability or unavailability of local resources to other computers in the network in a timely manner, Each time a computer joins the network, it requests the availability or unavailability of resources from other computers on the network, maintain a database of the availability or unavailability of resources on other individual computers in the computer network, According to the database validation, the resources of the specified computer were available before the resources of the specified computer were intended to be utilized. 2. A method for transmitting resource information between computers in a computer network, the operation steps of which include: Every time when the user computer works on the network, the user computer sends a request message to one or several predetermined server computers, Each predetermined server computer, in response to a received request message, determine whether the server computer can be used as a resource for the user computer, and Depending on whether the server computer is available or not, a positive or negative response message is sent to the user computer, respectively. 3, the method among the claim 2 also comprises following operation steps: When a server computer becomes available as a resource of a user computer, the server computer sends a requisition message to predetermined one or several user computers. 4, the method among the claim 3 also comprises following operation steps: When a server computer cannot be used as a resource of a user computer, the server computer sends a stop-requisition message to predetermined one or several user computers. 5. The method of claim 4 further comprising the steps of: Each network computer saves a server database and a user database, and each user database has several entries, indicating that this computer can be used as a resource for each network computer; each server database has several entries, indicating that it can Other network computers that this computer acts as a potential resource for. 6. The method of claim 5, wherein each entry in the server database includes a "requisition" item, for which item the method further comprises the steps of: In response to a requisition message about a computer, the "requisition" entry in the server database entry is set to a first predetermined state. 7. The method of claim 5, wherein each entry in the server database includes a "requisition" item, for which item the method further comprises the steps of: When a positive or negative response is received from the relevant computer after the request message is sent to the relevant computer, the item "Requisition" is set to the first or second predetermined state respectively. 8. The method of claim 5, wherein each entry in the user database includes a "requisition" item, for which item the method further comprises the steps of: In response to a "requisition" message sent to the associated computer, the "requisition" entry in the active database entry is set to a first predetermined state. 9. The method of claim 8 further comprising the step of: In response to the "Stop Requisition" message sent to the associated computer, the "Requisition" entry in the user database entry is set to a second predetermined state. 10. The method of claim 5, wherein each entry in the server database includes a "requisition" item, the method further comprising the steps of: When receiving the stop requisition message from the relevant computer, the "requisition" item in the server database entry is set to the second predetermined state. 11. The method of claim 5, wherein each entry in the user database includes a "permission" entry, for which entry the method further comprises the steps of: A requisition message is sent to the network computer only when the "permission" flag in the relevant user database entry is set to a first predetermined state. 12. The method of claim 5, wherein each entry in the server database includes a "permission" item, for which item the method further comprises the steps of: The "Requisition" item in the server database entry is set to the first predetermined state in response to the requisition message only if the "Permitted" item in the entry is placed in the second predetermined state. 13. The method of claim 6 or claim 7, wherein the step of determining whether the server computer is available comprises: Query whether the "requisition" item is in the first state. 14. A method for transmitting resource information between computers in a computer network, comprising the following steps: Each time when the user computer is connected to the network, the user computer sends a request message to one or several predetermined server computers, and each scheduled server computer, in response to a received request message, determines whether the scheduled resource on the server computer is available for user computing use, and If the resource is available or unavailable, a positive response message or a negative response message is sent to the user computer, respectively. 15. The method of claim 14 further comprising the step of: When a predetermined resource on the server computer is available to the user computer, the server computer sends a requisition message to one or several predetermined user computers. 16. The method of claim 15 further comprising the step of: When the reserved resources on the server computer cannot be used by the user computers, the server computer sends a stop requisition message to one or several reserved user computers. 17. The method of claim 16 further comprising the step of: Each network computer saves a server database and a user database, each user database has several entries, indicating that this computer can provide them with predetermined resources for each network computer, and each server database has several entries, indicating that this computer Individual network computers from which resources can be obtained. 18. A method for transmitting resource information between computers in a computer network, comprising the following steps: Each network computer saves a server database and a user database, and each user database has several entries, indicating that this computer may be used as each network computer of their resources, and each server database has several entries, indicating that it can become Each network computer for this computer resource, When the server computer becomes available as a resource to the user computer, the server computer sends a requisition message to the user computer, Each computer, in response to a received requisition message, registers an availability indication in a response entry in the computer server database, When the server computer cannot become a resource of the user computer, the server computer sends a stop requisition message to the user computer, Each computer registers an unavailable indication in the corresponding entry of the computer server database in response to the received stop requisition message, When requesting computers to join the network, these computers send an availability request message to the server computer, register an indication of availability or unavailability in the corresponding entry in the server database of the requesting computer based on a message obtained from the server computer responding to the request message, and at the same time, Before each computer intends to use a server as a resource, it determines whether the server is available or unavailable based on the computer's server database.

Images