

	     JavaGroups - A Group Communication Framework
	     --------------------------------------------


				 Bela Ban
			      4114 Upson Hall
			    Cornell University
			    bba@cs.cornell.edu
		    http://www.cs.cornell.edu/home/bba
			      March 29, 1998





1 Overview

JavaGroups is an extensible group communication framework, written entirely
in Java. It allows both reliable communication between single objects or
processes and between object- or process groups. Communication can be
asynchronous (sender does not wait for response) and synchronous (sender is
blocked until receiver sends response). Information is exchanged in the
form of messages, which are simple Java objects with a) a destination
address, b) a source address and c) a byte buffer with the contents of the
message.

The main components of JavaGroups are the Transport, which takes care of
sending and receiving messages over the network, the Dispatcher, which uses
the Transport to send messages ob behalf of objects and dispatches incoming
messages to objects, and the Group Membership Service (GMS) which is a
distributed directory service keeping track of all groups and their
members. Clients that want to work on the process level mainly interact
with the Transport, clients wanting to work on the object level mainly use
the Dispatcher.



2 Transport

The Transport is used for sending and receiving messages. It contains a
number of threads that send data, a number of thread that listen for
incoming messages, and a number of threads that listen for incoming
multicast messages. Clients can invoke the Send() method to send a
message. To receive a message, however, they have to register as a
MessageListener with the Transport and will be passed all incoming messages
when they arrive. (It is planned to add a Receive() method to the Transport
later).

A Transport uses a number of Protocols, stacked on top of each other, to
process outgoing and incoming messages. A Protocol is a Java interface that
prescribes a number of methods that have to be implemented. A Protocol
stack is assembled when starting the Transport given the names of the
classes implementing interface Protocol, and configuration strings. These
classes will then be loaded into memory by their class names.

A Protocol has to implement methods Send() and Receive(). The former is
invoked by the Protocol instance above it, the latter by the one below it
to pass messages down or up the protocol stack.

A Protocol will typically either modify the Message (e.g. encryption,
checksumming, fragmentation) or reorder it before delivery (e.g. for
maintaining FIFO order with respect to a certain sender, or for keeping
track of the message IDs received and optional retransmission).

As Protocols maintain certain properties required of a particular
instantiation of a Transport, they are among other things responsible for
the reliablility of message transmission.



2.1 Messages

Messages are modeled after IP messages which contain a destination, some
payload and a source address. The source address is a unicast address,
which allows a receiver to return a response to the sender. The destination
address might be a unicast, multicast or multiple address, which allows to
send a message to a single destination process or object, a group of
objects or a number of single objects or processes. The payload is a
RawMessage which is essentially a byte buffer.




3 Dispatcher

The Dispatcher is used by objects or groups to register themselves, which
allows other objects or groups to send messages to them. Each object has an
object ID which is a unique number within the Dispatcher. An object is
identified by the host name, the transport ID, and the object ID. The
transport ID is a number assigned to each Transport, and is guaranteed to
be unique within the same JVM.

When a Dispatcher receives a message, it checks to see whether it is a
unicast, multicast or multiple message. In the first case, the object to
which the message destination refers is looked up and the message passed to
it, in the seconds case, the message is passed to all members of the group
(the group is looked up first) and the last case is the same as the first,
except that the message is passed on to all objects specfied in the
multiple address destination of the message.



4 Group Membership Service

The GMS keeps track of the groups in the system and their members. Each
group is identified by a name, and a member is identifed by its host,
transport ID and object ID.

GMSs collaborate with other GMSs, forming a process group and providing a
distributed replicated group directory service. When new groups are
created, or deleted, members join or leave, the GMS broadcasts a message to
the GMS group, so that all member GMSs can update their local
database. Each GMS uses a Transport instance that supports totally ordered
communication to exchange information with its peers.




5 Groups

Clients don't usually interact with the GMS, but with the Dispatcher. When
new groups are to be created, or existing ones retrieved, they invoke the
corresponding methods of the Dispatcher. The Dispatcher passes the request
on to the GMS, which performs the required action. Then a Groups object is
created, containing the relevant group information, which is a group
address and name. Groups themselves do not contain membership information
(the list of members). Membership information is maintained exclusively by
the GMS (of course it may be cached by clients if they wish to do so), and
retrieved when required. This is the case when sending a multicast message
to all members of a group: if the group address is not an IP multicast
address (in which case a simple IP multicast message is sent), the member
list is retrieved and a unicast message sent to each member.
