MCS-378 Lab 4: Distributed Communication, Fall 2000

Due: December 13, 2000

Goals of the lab

In this lab, your team will get some experience using RMI, the Java Remote Method Invocation facility, which is one example of a modern distributed object system. To do this, you will write a simple "chat" program, which can be used to converse with other network users. Each user of the chat program identifies himself/herself with a "handle" (name) which can be the same as the username or chosen arbitrarily. Each user also selects a chat "channel" to participate in. Any message sent to that channel will appear, prefixed by the sender's handle. A message can at any time be sent to the selected channel. If the channel is changed, the area displaying received messages is cleared out.

Resources

You can use as starting point a dummy chat program, which I have as a Dummy.java file linked to the web version of this lab handout. This provides the graphical user interface, but doesn't actually do any network communication. Instead, it just displays your own messages locally. (You are welcome to improve on the user interface if you want, but that isn't the focus of the lab. The focus should be on adding the RMI communications to make the chat program real.)

You will probably want to consult the RMI documentation, which is on the web at http://java.sun.com/products/jdk/1.1/docs/guide/rmi/. In particular, this includes the RMI Tutorial, the code from which I showed on the overhead in class.

You may also need to look at some other Java documentation, such as that for the Choice class, which is used for the channel selector.

Your friendly neighborhood instructor is also a resource.

Hints

Remember that the client and the server are quite asymmetrical. The clients will need to find the server by name, but can then register with the server, so that the server knows the clients without doing a naming lookup. Similarly, when the client discovers that the server has failed, that is quite a different matter than when the server discovers that the client has failed.

You will almost certainly find it less hassle to leave the client a stand-alone application program rather than make it an applet.

You will also almost certainly find it less hassle to have all messages go by way of the server rather than directly from one client to the other clients on the same channel.

Unless you want to do a lot of grungy stuff, in order for an object to be remotely accessible using RMI, its class needs to extend java.rmi.server.UnicastRemoteObject (as well as implementing some interface that extends java.rmi.Remote). This causes a bit of a problem if you try making your GUI client class be remotely accessible. You are likely to want it to be a subclass of java.awt.Frame, and also of java.rmi.server.UnicastRemoteObject. But it is only possible for a Java class to extend one other class. The solution is to redesign your client to use two collaborating objects of different classes. One can be the GUI part and extend Frame. The other can be the remotely accessible part and extend UnicastRemoteObject.

When your server binds itself to a name in the RMI registry, you don't need to specify what host to use, if (as usual) you are going to use the local host. Instead of the RMI tutorial's

Naming.rebind("//myhost/HelloServer");

You can and should just use

Naming.rebind("/HelloServer");

Of course, use a different name than HelloServer: one that is descriptive, but also will be specific to your group, to avoid clashes with other groups if you use the same machine.

On the client side, you will need a full hostname to connect to, e.g., something like

Naming.lookup("rmi://oriental.mcs.gac.edu/MaxChatServer");

where oriental.gac.edu would be replaced with the host name and MaxChatServer with the name to which your server bound itself. To avoid having to hard-code a name like this into your client program, an alternative would be for you to specify it on the command line when you run the client. The command line arguments are available as an array of Strings passed to main.

Possible extension

There are lots of extensions you could do, but one that comes particularly to mind is making the choice of channels more flexible. Right now, the client program has built into it the names of the channels. Instead, you could have that knowledge only in the server, with the clients retrieving an array of channel names from the server.

Instructor: Max Hailperin