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).
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:
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
script with the
You need only hand-in one copy of your program.
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
- 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).
March 14, 2003 19:30: turn in a draft
of your User Guide.
April 16, 2003 23:30: turn in your complete
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
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.
- Multi-player Go Fish
- 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
- 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
- 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.
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.
This page is online at http://www-all.cs.umass.edu/~fagg/classes/377/labs/lab3/index.html
Andrew H. Fagg