CMPSCI 377: Operating Systems
Lab 3: Interprocess Communication

Due Dates: March 14, 2003 19:30 (User Guide draft)
April 16, 2003 23:30 (complete program)

Purpose of Assignment

This assignment will give you experience with communication between processes that are executing on different machines (and hence located within different JVMs).

Grading

This lab project will count for 30% of your lab grade (so 11.7% of your final grade).

Program Design and Implementation (including data structures): 40%
Correctness: 40%
Documentation: 20%

You may work with one other person in the class. If you choose to do so, please send email to the professor and the TAs in order to indicate who your partner will be and which of the two of you will be handing in the program. Do not share/accept code with/from anyone else or the net.

Where to do your work

For this lab, place your final submission in the following directory:

~/cs377/lab3

If your files are not located in the right place or our robot cannot read your homework at the time of submission, then we will not be able to grade it. In order to make sure that our robot can pick up your program, please check things by executing the ~fagg/bin/checkhw script with the lab3 parameter.

You need only hand-in one copy of your program.

The Problem

For this lab, you are required to implement a multi-player game. The requirements are as follows:

The game rules may be of your own design, and must be reasonably interesting (if in doubt, ask). At the very least, the game must have at least 10 turns.
Your game must support at least 4 simultaneous players.
The user interface does not need to have a graphics component, but it is recommended.
The two programs must detect and deal with failures in communication (e.g., the disconnection of one of the processes). This does not necessarily mean that the game must still continue in the face of drastic failures...
For interprocess communication between the different programs, please use Java TCP Sockets or Java RMI (I suggest the latter). Depending upon the structure of your program, you may find it convenient to use multiple threads within each of these processes.

What to Hand In

Place in your Hand-In directory the following:

An appropriately documented set of java source files (e.g., "server.java", "client.java")
Two executable classes that you have compiled for and tested on the elnux system:
- A server program that will implement the game rules.
- A client program that players will execute. This client will connect into the server program (at a command-line specified location and a default port).
A "lab3.ps" file that contains:
- Your name(s)
- Your UID(s)
- The name of your top-level java class
- A User Guide that explains how to use your program and the rules of your game. This should be complete enough that a (reasonably) naive user could use your program.
- A Design Document that explains the main modules and data structures that you use in your program.
- Your entire document should not exceed 20 pages (with figures).

Important Dates

March 14, 2003 19:30: turn in a draft of your User Guide.

April 16, 2003 23:30: turn in your complete program

April 23, 2003 17:00: by this date, demonstrate your program to one of the TAs or the Instructor. You may do this during their office hours or by appointment (don't try to make appointments at the last minute).

Testing Your Program

Before handing in your program, make sure to test it carefully with at least 4 users (recruit your classmates, friends, etc.).

We will check the correctness of your program during your demonstration.

Possible Projects

Poker
Multi-player Go Fish
Tank
Multi-player Pac-Man

Hints and Notes

Having trouble starting your server (strange exceptions being thrown when you try to bind the object). Try the following:

Make sure you have executed 'rmic' on your server implementation (since your last compile).
Make sure that your server/stubs are in the local directory or are in your CLASSPATH.
Restart the rmiregistry process (this requires that you first kill the process before restart). There appear to be some oddities in rmiregistry that can force it into a confused state.
If someone else is running the rmiregistry on your machine and you are in need of restarting it, consider specifying a different port number. This is a parameter to rmiregistry; the same port number must be specified in your server and client URLs (for bind and naming calls). For example, you could use "rmi://localhost:7777/GameServer", where 7777 is the port number.

If you see: 'port already in use' when you try to start the rmiregistry, this means that one is already running. You may or may not have to restart this process, depending upon the conditions. NOTE: make sure to kill your rmiregistry process when you are done for the day.

RMI Registry: I strongly suggest that you pick your own rmi registry port (you can specify it with the -p option of the rmiregistry program). Also - when you are done using the registry on a machine, please make sure that you kill it.

Poker player hints: Here are some hints from my implementation of the poker player.

Java Hints

This page is online at http://www-all.cs.umass.edu/~fagg/classes/377/labs/lab3/index.html

Andrew H. Fagg

CMPSCI 377: Operating Systems Lab 3: Interprocess Communication Due Dates: March 14, 2003 19:30 (User Guide draft) April 16, 2003 23:30 (complete program)