Abstract interface features

When a member joins a caucus, it receives an identity unique within that caucus. The framework sends the identity with each caucus message, providing caucus members with a way to identify the source of incoming messages.

NOTE Each caucus member is associated with a single caucus, though a client can join the same caucus multiple times by creating additional TCaucusMember instances. Each caucus member possesses a unique identity within the caucus, even if it shares a thread with other caucus members.

Caucus members communicate by creating send message objects and receive message objects.

Typically, a caucus member receives messages using a thread devoted to this operation. The thread loops continuously, attempting to create a TCaucusReceiveMessage or TStandardCaucusReceiveMessage object (as appropriate to the implementation you choose). The thread blocks as long as there is no incoming message; once a message is available, the thread unblocks, streams out the message, and destroys the object. "Receiving messages from a caucus" on page 53 describes this procedure for the standard implementation.

Caucus members send messages using TCaucusSendMessage or TStandardCaucusSendMessage objects. These objects work similarly to the receive message objects--to send a message, you create a send message object, stream in the data, then destroy the object. The caucus sends the message to all caucus members, including the originator.

NOTE In order to send messages, a caucus member must also receive messages. If no thread is currently receiving messages for a caucus member, a thread attempting to send a message to the caucus can block forever.

To leave a caucus, a caucus member calls its Leave member function. Leave automatically sends a message to the caucus. Once a member leaves, the identity it assumed while in the caucus is released and is available for re-use. If the client later rejoins the caucus, it creates a new caucus member and thus obtains a new identity.