Distributed Systems 2008

How do you multicast using Java RMI?

2008-09-30 13:00

The algorithms in the book for multicast that you will use are those that implement multicast using repeated unicast (one to one communication). So, how should one send data using Java RMI in this way? The easiest way is to give all GCom instances some "communication device" object with a method that we in this example can call receiveMessage. When a group member A wishes to send some data to the group, it iterates over the group members and (using Java RMI) sends the data by calling the remote instances' receiveMessage method, supplying the message as a parameter.

In pseudocode, this would look as follows (for unreliable multicast):

for each member m of the group g:
  m.receiveMessage(message)

Please note that we must ensure that the receiveMessage method returns as quickly as possible. The sender (A, in the example) would otherwise wait for the method to return for a long time, possibly also with confusing side effects due to upper layer activities. Ideally, we want to put all the messages in some queue at reception so that the pseudocode for receiveMessage is merely as follows:

function receiveMessage(message)
  messageQueue.enqueue(message)
  return

What is a "local member"?

2008-09-09 10:35

A "local member" is the process' own member object. A "local member name" is some string the process should be known as. So, for instance, in a chat application, a process may wish to join the group "distributedSystems" with the local member name of "larsson". Because such display names are not unique, a Member object also has an actual globally unique identifier (allowing several members to be known as "larsson", but still being uniquely identifiable). It is not up to the application to make such a unique identifier, it is up to GCom (thus explaining why we send a string parameter to join or create a group, whereas we get a Member object that contains our actual unique identifier in return from getLocalMember).

How does an application communicate with GCom?

2008-09-09 10:30

An application communicates with GCom to create a new group, or join a group that already exists. It can also leave the group, using the appropriate method. Once in a group, the application should register objects that receive events related to group changes and message delivery. Because this uses the observer/observable design pattern, the intention is that there may be several objects that listen to such events (keep a list of them!).

How should GroupDefinition be used, and how are groups connected to?

2008-09-05 09:40

A group is defined by an object of a class implementing the GroupDefinition interface. Such objects are used to represent the group completely. Somehow, depending on your design, these objects can be retrieved from GCom using the listGroups() method. Once obtained, one may fetch a suitable group's name and issue a call to the joinGroup() method. Or, alternatively, if one already knows the name of the group to join, it is possible to just join using the name immediately. The return value is some object implementing the GroupDefinition interface, and your middleware should set itself up to handle the group communication according to the specified parameters.

Note that the implementation of the GroupDefinition interface can differ between GCom for internal use, and your test programs. This is perfectly fine.

Where should the RMI registry be located?

2008-09-05 09:35

This is completely up to you and your design. There will not be a central RMI registry that all solutions must connect to, so each pair solving the assignment is free to run their own RMI registry or registries. It is possible to solve the assignment using a separate registry, or to have one for each of your GCom nodes. This is something you should consider in your design, and clearly state the reasons behind your choice in your first deliverable.