Group communication offers a service whereby a message is sent to a group and this message is delivered to all members of the group. In this action, the sender is not ware of the identifies of the receivers.
Group communication represents an abstraction over multicast communication and may be implemented over IP multicast or an equivalent overlay network, adding significant extra value in terms of managing group membership, detecting failures and providing reliability and ordering guarantees.
The programming model
In group communication, the central concept is that of a group with associated group membership, whereby processes may join or leave the group. Processes can then send a message to this group and have it propagated to all members of the group with certain guarantees in terms of reliability and ordering.
Thus, group communication implements multicast communication, in which a message is sent to all the members of the group by a single operation. Communication to all processes in the system, as opposed to a subgroup of them, is known as broadcast, whereas communication to a single process is known as unicast.
The essential feature of group communication is that a process issues only one multicast operation to send a message to each of a group of processes (in Java this operation is aGroup.send(aMessage)) instead of issuing multiple send operations to individual processes.
Most work on group services focuses on the concept of process groups, that is, groups where the communicating entities are processes. The level of service provided by process groups is therefore similar to that of sockets.
In contrast, object groups provide a higher-level approach to group computing. An object group is a collection of objects (normally instances of the same class) that process the same set of invocations concurrently, with each returning responses. Client objects need not be aware of the replication. They invoke operations on a single, local object, which acts as a proxy for the group. The proxy uses a group communication system to send the invocations to the members of the object group. Object parameters and results are marshalled as in RMI and the associated calls are dispatched automatically to the right destination objects/methods.
Implementation issues
In group communication, all members of a group must receive copies of the messages sent to the group, generally with delivery guarantees. The guarantees include agreement on the set of messages that every process in the group should receive and on the delivery ordering across the group members.
Group communication systems are extremely sophisticated. Even IP multicast, which provides minimal delivery guarantees, requires a major engineering effort.
As well as reliability guarantees, group communication demands extra guarantees in terms of the relative ordering of messages delivered to multiple destinations. Ordering is not guaranteed by underlying interprocess communication primitives. For example, if multicast is implemented by a series of one-to-one messages, they may be subject to arbitrary delays.
To counter this, group communication services offer ordered multicast, with the option of one or more of the following properties:
- First-in-first-out (FIFO) ordering (also referred to as source ordering) is concerned with preserving the order from the perspective of a sender process, in that if a process sends one message before another, it will be delivered in this order at all processes in the group.
- Causal ordering takes into account causal relationships between messages, in that if a message happens before another message in the distributed system this so-called causal relationship will be preserved in the delivery of the associated messages at all processes.
- In total ordering, if a message is delivered before another message at one process, then the same order will be preserved at all processes.
Reliability and ordering are examples of coordination and agreement in distributed systems.