Peer protocols

Protocols can be categorized according to their interaction with other protocols: some protocols interact primarily with their neighbor protocols in the same stack, and others interact with their corresponding peer instances on different protocol stacks. Therefore this type of interaction can be called vertical interaction:

• pass a message to its neighbor (up or down the stack) unchanged,

• add a header to the message, but not modify it,

• modify the message, add a header and pass it on (e.g. encryption, fragmentation layers),

• reorder the message (e.g. FIFO, TOTAL layers) or

• discard the message (e.g. DUPL layer)

These tasks can easily be done with protocol layers inheriting from Protocol.

The second types of protocols interact not primarily with other layers in the same stack, but with their equivalent peer instances in different stacks. Therefore this type of peer protocol interaction is called horizontal interaction. A typical peer protocol is a group membership service (GMS) layer which needs to interact with the GMSs in all member stacks to e.g. install a new view.

Peer protocols frequently involve sending a request to all member peer protocols, where the request is received and processed, and possibly a response sent back, received by the originator of the request. The above case requires quite some work on behalf of the programmer: a request has to be given a unique request number, it has to be sent to all members, the receiving stack has to make sure that the correct destination layer receives it, then it will be processed, possibly a response may need to be returned, in the sender's stack it has to be sent to the correct (originating) layer, and the requester has to correlate the response(s) with the original response. This is especially complex when a sender can send multiple requests concurrently.

The two protocols discussed below try to address this issue. Their goal is to provide a minimal framework for (synchronous) peer protocol interactions. It uses classes RequestCorrelator and GroupRequest to do so (see sections 3.4.3 and 3.4.4 respectively).

The idea of peer protocols is that every peer can send, but also receive requests, i.e. every peer is a client but also a server possibly at the same time. A peer in the client role would send a request to all peers and receive the response(s) synchronously, i.e. it would block until all responses have been received. A peer in the server role would receive requests, process them and return a response. The two basic elements of 'sending request/receive response' and 'receive request/return response' have been incorporated into MessageProtocol. This class is derived from Protocol and extends it with peer interaction as described above. Any protocol that needs to interact with peer protocols may benefit from the additional methods present in this class, by inheriting from it rather than from Protocol directly.

Whereas MessageProtocol deals with messages, RpcProtocol deals with methods. The latter allows peers to define methods which can then be invoked remotely by other peers (instead of receiving messages as with the former class). RpcProtocol is derived from MessageProtocol. The two types of peer protocols are discussed below.