RequestCorrelator

Typical protocols can be divided into protocols that perform some work on a message, and then pass it up or down the stack, and protocols that interact with their peers in different protocol stacks^3.6. The latter often need to send requests to their peer(s) and receive responses. However, in distributed peer computing (as is the case in groups), any member may be the originator and receiver of a request. That means that - besides sending requests and receiving the corresponding responses - every member must be enabled to process requests sent by other members and send responses. The main functions of a peer protocol are therefore

Send requests

Send a request (message) to a single or all group members and receive 0 or more responses. If the request is asynchronous, no responses will be received. It should be possible to specify how many responses are to be received, e.g. all, majority, first.

Receive responses

Receive a response to a request. If the request was sent to the whole group, receive a number of responses. No response will be received if the request was sent asynchronously. If a member has crashed before sending a response in the synchronous case, its response should be marked as 'not received'. Note that correlation between requests and responses is important, i.e., if a sender sends out requests r1, r2 and r3, incoming responses have to be matched against their originating requests.

Receive request

Receive a request sent by a group member, process it and send a response (see below). Since local messages are enabled on a channel by default, a sender will receive its own request and has to process it like any other group member.

Send response

Send a response to a request. Usually invoked when done processing a request.

The above functionality has been incorporated in class RequestCorrelator (JavaGroups.RequestCorrelator). This class can be used in an application on top of a channel, or to implement a peer protocol. The only requirement is that clients of the class provide a Transport instance for sending requests/responses and call Receive or Suspect respectively, whenever a request/response is received or a member suspected.

The structure of a request correlator is shown in fig. 3.4.

  

Figure 3.4: Request correlator

Essentially, a RequestCorrelator has 1 object that is responsible for handling all requests (RequestHandler), and 0 or more response handlers (RspCollector) which will receive the response(s) for a specific request. Each request is identified by a unique ID (for example the current time in milliseconds) and added to a request table. When a response comes in, its ID is matched against the requests, the correct request is found and the response directed to it. Having multiple requests pending at any time (compared to just a single one) gives clients of request correlator more freedom: the decision whether to send a single or multiple requests at a time is theirs.

The RequestCorrelator has methods to a) send a request (synchronously or asynchronously, to a single member or to all group members), b) submit a suspicion message, c) make it receive a message and d) remove a request (calling method Done with the request ID). It allows to register a request handler which will handle all requests directed towards this request correlator.

The following actions take place when a group request is sent: