Method and Apparatus for Managing Multiple Server Requests and Collating Reponses

This invention relates generally to computer communications systems and more particularly to a mechanism and process for dispatching a request from a client to a number of servers, receiving responses from the servers, and returning a collated response to the client.

In the "client-server" model of interaction in a distributed system, a program at one site sends a request to a program at another site and awaits a response. The requesting program is called a client; the program satisfying the request is called the server.

Communications networks allow clients and servers to exchange information by transmitting and receiving messages on the network. Currently, in order to obtain information from the servers, a client will send a remote request individually to each server from which the client requires information. Also, if the client does not know the address of the server of interest, it will use an external nameservice lookup which returns the server address. The client can then proceed with the individual request to the server.

This prior art technique is illustrated in FIG. 1. The process includes determining a request and the servers of interest (step 91), sending the request to a server (step 92), waiting for all of the responses from the server (step 93), and processing the responses (step 94). Each of steps 92-94 are repeated for each server.

This prior art technique does not provide for a single client request automatically translating into multiple (simultaneous) requests to multiple servers depending on the client's domains of interest. Furthermore, it requires that the client know the address of each server; the client must specify this address in each request. Further, the existing technique does not provide a collated response to multiple requests, even if the multiple requests are related. Also, there is also no overlap in time of the responses received. Instead, each request/response sequence is completed before a request is sent to the next server.

The present invention provides an apparatus and method for dispatching multiple requests from a client and for generating a collated response.

The method includes the steps of receiving from the client a request with a list of server domains of interest, mapping each domain to at least one server address, dispatching the request to each server address, receiving responses from each server, generating a collated response from the responses, and providing the client with the collated response.

In select embodiments: the collated response includes responses ordered according to the domains; and the collated response triggers a process in the client. The method can be used successfully for different protocols.

The apparatus of the invention may include a domain-to-server mapper which accesses an internal cache of domain/address mappings. The apparatus may further include a dispatcher for sending simultaneous requests to multiple servers and a receiver for receiving multiple responses simultaneously and storing the responses in a context table which includes an anchor context and a number of dependent contexts. A context is provided for each contacted server, and when all responses from a given server are received, it is transferred to the anchor context for providing a collated response to the client.

These and other advantages of the present invention will be more particularly described with respect to the following detailed description and figures.

FIG. 1 is a block diagram of a prior art method for sequentially sending requests to servers and receiving responses;

FIG. 2 is a block diagram illustrating one apparatus embodiment of the present invention;

FIG. 3 illustrates one method of collating a response in accordance with the present invention;

FIG. 4 is a flow chart of the overall method of the invention; and

FIG. 5 shows a general purpose computer and memory for implementing the present invention.

FIG. 2 depicts one embodiment of the apparatus of the present invention. A client 101 may have one or several requests for information to be sent to one or several servers, for example server-1 (102), server-2 (103) . . . and server-N (104). These servers may reside on a single network 105, or several networks. Instead of specifying a server address as in the prior art, the client specifies a domain of interest and sends a request to a request manager 106. Within the request manager 106, a dispatcher collator 107 receives the request from the client. In this embodiment, the dispatcher collator includes a domain-to-server mapper 108, an internal cache 109 of server addresses, and a mechanism 110 for accessing an external nameservice process 112.

The domain-to-server mapper 108 determines which servers are associated with the domain of interest specified by the client 101. The client 101 may specify more than one domain of interest in a single request. The dispatcher collator 107 then passes the associated server addresses to the request dispatcher 111. In this embodiment, the mapper 108 checks the internal cache 109 for the server addresses, once the servers have been identified from the domain of interest. If the internal cache 109 does not contain the addresses for any of the servers within the domain of interest, the lookup mechanism 110 queries an external nameservice 112 to determine the same. In such an instance, the addresses requested from the external nameservice 112 will then be stored in the internal cache 109, so that next time the dispatcher collator 107 can access the addresses without invoking a nameservice query.

The scope of the invention is not limited by any particular form of the internal cache 109. In one embodiment, the cache 109 may be preset by the client 101 as an option. In such an instance, the client 101 may prespecify a list of domains of interest.

The request dispatcher 111 creates multiple request messages, normally one for each server. The request dispatcher 111 also creates a request context for each request and stores the same in a request context table 113. One of these contexts is designated the "anchor" context 114, and the remaining contexts are treated as "dependent" contexts 115, 116. Each of the dependent contexts 115, 116 has a reference to the anchor context 114. A context may be added to the request context table 113 and indexed by a unique number, such as an exchange identifier. In such an example, each request message sent to a server may also be tagged by the exchange identifier.

The request dispatcher 111 simultaneously sends a request message to each of the designated servers. In this embodiment, each time the request dispatcher 111 sends a request, a session count 117 within the anchor context 114 is incremented by one. Later, as the session with a particular server ends (indicated by either NO.sub.-- DATA.sub.-- FOUND, or NO.sub.-- MORE.sub.-- DATA or an error condition), the session count is decremented as described hereinafter.

Responses from the servers (102-104) may be received in any order, i.e. the responses may be asynchronous and interleaved. Normally, the order and amount of responses received from each server is completely unpredictable. This is because the order of receipt is influenced by such factors as the amount of relevant data stored by the server, the network distance between client and the server, etc. However, all of the responses received from any server are tagged by the same exchange identifier that was used for tagging the request that generated these responses. The response receiver 118 uses the exchange identifier associated with the response in order to identify the correct context. The response message received may then be stored in a message store area 120, shown in the request context table, where there is one message store area associated with each anchor context 114 and each dependent context 115, 116.

Normally, a server will set a no-more-data flag in a response when a session between the request manager 106 and a specific server is complete. When such session is complete, all of the responses from the message store of that context are transferred to the collated message store 121 in the anchor context. When each such transfer occurs, the session count is decremented by one, indicating that all responses associated with a particular context (i.e., coming from a single server) have been received. When the session count reaches a zero value, indicating that all responses from all contexts (both anchor and dependent) have been collated in the collated message store of the anchor context, the request manager 106 sends the collated message back to the client 101. In one embodiment, the responses within the collated message are placed in an order according to the server from which they were received. When the session count reaches zero, the dispatcher collator triggers a process 119 (pre-specified by the client at the initiation of the request) within the client 101 with a single collated response.

The server domain of interest can vary depending upon the application in which the response manager 106 is used. In general, a domain of interest is a sphere of control of a server, for example an entity or set of entities which the server controls, or which the server is responsible for. Examples of server domains include the set of network services that are managed by a single Cabletron Spectrum.TM. server (sold by Cabletron Systems, Inc., Rochester, N.H.), a database or databases managed by a single database server, a DCE (distributed computing environment), an X.500 standard cell, or a group of entities whose name/location service is provided by a cell-directory server.

A client may process a request, and then determine the domain of interest associated with the request. The domain of interest may be internally generated, may be received from an external device, or may be received from a user. As described above, the request manager processes these requests by mapping the domains of interest into a list of network server addresses, sending the request to each of the servers, and receiving and collating the received responses.

Thus, the invention enables a client to dispatch any information request to a desired set of servers by identifying only the request and the domains of interest. The invention is independent of the type of request or the communication protocol used between the client and servers. For example, an SNMP client may use this mechanism to send simultaneous requests to multiple SNMP servers (agents) and receive a single collated response; in the same way, a database client may send simultaneous SQL requests to multiple database servers and receive a single collated response. As used herein, "server" is broadly defined; the invention may be used for requesting responses from devices, such as other clients or other host computers; thus, as used herein, "server" includes such other devices.

Each server may send one or more responses for each request. Additionally, the request manager's session with each server may end in any order. In other words, multiple parallel sessions with multiple servers may continue, and the sessions do not have to end in the same order as the order in which the requests were sent. In one embodiment, the client has an option to indicate a specific process/action that needs to be triggered on receipt of all of the responses from all of the servers.

One process of collating a single response is illustrated in FIG. 3. An input stream of responses 31 for a particular request may be received in any order. As shown, the order of receipt in this example is "RSP 1 from S1" (32), "RSP 1 from S2" (33), "RSP 2 from S1" (34), and "RSP 2 from S2" (35). S1 indicates a first server to which a request was sent, and S2 indicates a second server to which a request was sent. However, it may be advantageous to the client to have the responses collated in a different order than received, e.g., by server. In this example, a collation process using the anchor/dependent context 36 provides a collated response 30 such that response 1 from S1 (32) and response 2 from S1 (34) are first provided in serial order, and response 1 from S2 (33) and response 2 from S2 (35) are next provided in serial order. The single collated response 30 is then provided to the client.

FIG. 4 illustrates generally the process steps in accordance with the present invention. In step 41, a request is received from a client. This request includes a domain of interest, or a number of domains of interests. Step 42 determines the servers from the domain or domains of interest, and also determines the address for each server. In step 43, the individual requests are dispatched to the servers, and in step 44 responses from the servers are received and collated. In step 45, the client is provided with a collated response. As indicated above, an internal cache may be used in step 42 to determine the server addresses, and a nameservice mechanism may also be used to determine the addresses. Furthermore, a request context table may be generated, which for each request, includes an anchor context and at least one dependent context. If the request is going to a single server, the anchor context and the dependent context are one and the same. In case the request is going to more than one server, one of the contexts is the anchor context and the rest are dependent contexts. The anchor context includes a session count, so that as responses are received and collated from a server, the session count can be decremented. This session count is initially incremented when each server is sent a request, as in step When the session count is decremented to zero (when all messages for all the requests are received), then the client may be provided with a collated response as in step 45. Alternatively, step 45 may trigger a process identified by a request within the client when the collator response is complete.

Any of the above embodiments may be implemented in a general purpose computer 90 as shown in FIG. 5. This general purpose computer may include a computer processing unit (CPU) 95, memory 96, a processing bus 97 by which the CPU can access the memory, and an interface 98 by which the CPU can interface to other devices.

In alternative embodiments, the invention may be a general purpose computer apparatus 90 which performs the functions of any of the previous embodiments. Alternatively, the invention may be a memory 96, such as a floppy disk, compact disk, or hard drive, that contains a computer program or data structure, for providing to a general purpose computer instructions and data for carrying out the functions of the previous embodiments.

Having thus described several particular embodiments of the invention, various modifications and improvements will readily occur to those skilled in the art and are intended to be within the scope of this invention. Accordingly, the foregoing description is by way of example only, and not intended to be limiting.