|
JGroups
Documentation
Download
Misc
|
|
Overview
|
JGroups is a reliable group communication toolkit written entirely in
Java. It is based on IP multicast (although TCP can also be used as transport), but extends it with
- reliability and
- group membership.
Reliability includes (among other things)
-
lossless transmission of a message to all recipients (with retransmission
of missing messages)
- fragmentation of large messages into smaller ones and reassembly at the
receiver's side
-
ordering of messages, e.g. messages m1 and m2 sent by P will be received
by all receivers in the same order, and not as m2, m1 (FIFO order)
-
atomicity: a message will be received by all receivers, or none.
Group Membership includes
-
Knowledge of who the members of a group are and
-
Notification when a new member joins, an existing member leaves, or an
existing member has crashed
The table below shows where JGroups fits in:
| |
Unreliable |
Reliable |
| One-to-one (unicast) |
UDP |
TCP |
| One-to-many (multicast) |
IP multicast |
JGroups |
In unicast communication,
where one sender sends a message to one receiver, there is UDP and TCP.
UDP is unreliable, packets may get lost, duplicated, may arrive out of
order, and there is a maximum packet size restriction. TCP is also unicast,
but takes care of message retransmission for missing messages, weeds out
duplicates, fragments packets that are too big and presents messages to
the application in the order in which they were sent. In the multicast
case, where one sender sends a message to many receivers, IP Multicast
extends UDP: a sender sends messages to a multicast address and the receivers
have to join that multicast address to receive them. Like in UDP, message
transmission is still unreliable, and there is no notion of membership
(who has currently joined the multicast address).
JGroups extends reliable unicast (one-to-one) message transmission (like in TCP)
to multicast (one-to-many) settings. As described above it provides reliability and group
membership on top of IP Multicast. Since every application has different
reliability needs, JGroups provides a flexible protocol stack architecture
that allows users to put together custom-tailored stacks, ranging from
unreliable but fast to highly reliable but slower stacks.
As an example,
a user might start with a stack only containing IP Multicast. To add loss-less
transmission, he might add the NAKACK protocol (which also weeds out duplicates).
Now messages sent from a sender are always received by the recipients,
but the order in which they will be received is undefined. Therefore, the
user might choose to add the FIFO layer to impose per/sender ordering.
If ordering should be imposed over all the senders, then the SEQUENCER protocol (providing total order)
may be added. The group membership (GMS) protocol provides
group membership: it allows the user to register a callback
that will be invoked whenever the membership changes, e.g. a member joins,
leaves or crashes. In the latter case, a failure detector protocol
is needed by the GMS to announce crashed members. If new members want to
obtain the current state of existing members, then the STATE_TRANSFER protocol
has to be present in this custom-made stack. Finally, the user may want
to encrypt messages, so he adds the ENCRYPT protocol (which encrypts/decrypts
messages and takes care of re-keying using a key distributiontoolkit).
Using composition of protocols (each taking care of a different aspect)
to build reliable multicast communication has the benefit that
-
users of a stack only pay for the protocols they use and
-
since protocols are independent of each other, they can be modified, replaced
or new ones can be added, improving modularity and maintainability.
|
|
|
