Distributed Systems 2014

How does this whole Java RMI and serialization business work?

2009-09-16 12:00

The guys at O'Reilly have explained it in detail. Read Chapter 10 of "Java RMI" (sample chapter) to find out all about deep copies, serialization, etc.

Some more implementation hints regarding the multicast and Java RMI?

2009-09-15 16:00

Certainly! Everything you send as a parameter to the receiving remote method will have to be serialized before being pushed over the network. Serialization of an object makes a deep copy of it (obviously, since a shallow copy will not be sufficient due to lack of shared memory). This means that if you let your Message class implement Serializable, then everything that your Message object has a reference to will also be serialized and sent along with it. Therefore, avoid non-essential references!

However, take a step back and consider what else you send. You most likely send a reference to the group leader to your message receiving class. Does that class have references to the other modules in your system? If so, those will be serialized along with it... and it is just not good programming to send the entire stack along if you just intended to send a reference to a simple component.

There are ways to deal with this, of course. A very good way is by using a BlockingQueue as suggested in last year's "How do you multicast using Java RMI?" question. Then, all that the message receiving component will have to maintain a reference to is that queue. And you should of course scrub your Message class clean from all references to non-essential objects, too. But it does not end there! There is also a keyword in Java especially for marking that a certain reference should not be serialized along with the rest. That keyword is transient. This is exactly what we want for the queue.

Why do we keep suggesting that you use a queue? Is it not sufficient to mark all references to the rest of the components as transient and be done with it? No. To understand why, keep in mind that when a method is called over Java RMI, the calling code will have to wait until the remote method returns. This means that unless the receiving process returns quickly, we will force the sending process to wait -- and (depending on what message is being sent), this could even lead to a deadlock among processes. Therefore, we want to just put the incoming message in a queue, return to the sender quickly, and then handle the message in another thread. Java's standard blocking queues provide us with just that feature, and is extremely easy to use, too.

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

The queue, in this case, may e.g. be a type of BlockingQueue, where you have a thread waiting to consume the messages that arrive in it.

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.