Project 3 is optional. You may choose to either complete the project
or take the final. By showing up for the final you implicitly choose
the latter option.
CSE 461 Project 3: Multicast and
Due March 19, 1998
More config files
Some additional config files are here:
- inet.cfg models some of the
internet. This will bounce stuff off Berkeley and MIT in addition to
hosts in Sieg and around the UW. You should probably avoid playing
with this until you have some pruning code that works.
Project 3 code
The code is available as a zip file (without the Visual J++ project
files). You will need to unpack the file, create the projects, and
put your own routing code into the network layer.
To run the project, do the following:
The code is here.
- Run java application.project3
config=application/simple.cfg to start the main network
- Run java application.Nebraska host1 4087 <hostname>
(where hostname is the name of the machine from step 1) to start the
- Run java application.Nebraska host1 4088 <hostname>
(where hostname is the name of the machine from step 1) to start the
For project 3 we are going to build a "real-world" multicast
application. This application is a graphical variant on a
"chat-room." The program allows users to create and manipulate blocks
in a 2D space (i.e. drag them around with the mouse). What makes this
application interesting is that it is multiuser, that is any number of
clients may run the application and they all get to manipulate the
same set of objects, watch what everybody else is doing, and
collectively work toward some goal.
If you are curious about the motivation for this project, take a look
at the Kansas
project at Sun Microsystems
Laboratories. This system, although based on a centralized
server, shows what a full-blown application of this flavor might
Largely as a consequence of implementing a real application with a
user interface, and also to give you a flavor of development on a real
network, much of the simulator for the previous projects has been
eliminated. We will retain a simulated topology controlled by a
config file, but the simulated timer will be replaced with real time
and the simulated links with actual network traffic using UDP. The
links from the clients into the network will be direct UDP links
(allowing each client to actually use a separate computer) and the
internals of the network will be simulated by bouncing packets off
remote hosts in the internet. This will permit us to get real
internet-like behavior while keeping all the processing physically
located at the UW.
The application as it exists is an AWT (the Java graphical interface)
application. If you run it you get a window with a little control bar
at the bottom that lets you enter a color (as RGB values) and a width
and height, and then create a new object (the objects are placed
randomly). Once you have some objects you can click and drag them
Objects are represented by a set of attribute values:
The object ids are assigned by each client based on a count and the
client's id (to make them globally unique). Whenever any of these
attributes change the application bundles up a message containing the
object id and the changed attributes, and sends that to the other
clinets. When messages are received the information is rolled into
the local state and the display is updated.
This program is a perfect application for multicast. If there are
more than two participants then updates generated at each client need
to be broadcast to all other clients. Mulitcast will allow us to
implement this efficiently.
The network will be set up as a bunch of your project 2 routers
connected by the "real" links. You will need to implement multicast
between your routers.
There are several multicast issues that will have to be dealt with,
either in the routers or the application, in order to make this
- Congestion control:
In order to avoid flooding the network and causing congestion
collapse, it will be necessary to implement some form of congestion
control to restrict the rate at which each client sends updates.
Based on the topology, it is likely that some hosts will be closer to
senders than others. In order to maintain acceptable performance it
will be necessary to allow near and far receivers to get different
data streams, so that nearby receivers can get more updates than
The application has a mechanism to handle this. Observe that the only
time the application tends to generate massive data streams is when
objects are being moved, so that the data stream consists of a series
of updates to a few attributes of a few objects. Such streams can be
condensed by rolling several updates on a single object into one
message containing only the last values for each of the changed
attributes. A data stream reduced in this way will result in jerky
motion, while the nearby clients can receive the full data and display
smoother motion. You can consider either generating several output
streams at the sending application (as is typical today) or
specializing your routers to understand the application and reduce on
demand (less realistic for the real internet, but probably a better
quality solution for us).
What happens if a packet is dropped. Most of the time this
application is robust to drops, because it is likely that the dropped
packet was a position update that will be overwritten by the next
packet anyhow. Some packets however, namely the initial packets sent
when objects are created, are more important. How will you discover
that you have missed an important packet? What should you do about
On a related note, this problem is similar to the problem of starting
up a new client when several others have already been working for a
while. How can you bring the new client up to date with the state of
At any given time there are likely to be nodes in the network topology
for which there are no active clients connected. You should implement
some scheme to prune off transmission to those parts of the network.
In particular it is important not to transmit packets across an
expensive link if nobody on the other side is listening.
Real time/real network issues
The use of real time measurement and network transmission in place of
simulated time and links has several implications:
- The Timer class is replaced with a greatly simplified
implementation. You can still use the timer for synchronization, as
project 2 did, and you can set timeouts. You should not expect timing
behavior to be anywhere near as precise. Also, the timer no longer
supports the WaitFor and WaitUntil methods. You can
use Thread.sleep, but be careful to avoid deadlock if you do.
- The real network links require that packets be converted to byte
arrays for transmission. This means that all the data fields in
NetworkPacket will need routines to convert them to and from
byte arrays. I will supply a ConvertToByteArray function and
a constructor which will handle the supplied fields, but you will need
to extend these routines to support any other fields that you have
Formal evaluation of this project will be limited. Your program is
required to use multicast, and this will be verified by code
inspection or performance. Your goal with this project is to provide
a usable application for groups of three or more clients organized in
clusters (i.e. groups of clients with fast links inside the groups and
slow links between the groups).
There will be a final demonstration of your project to show how well
it works. More info on this to follow.
Just as in projects 1 and 2, this assignment should be done and handed in
in groups of 2-3. Since this project is optional you may need to
You will need to schedule design reviews for this project
independantly. Contact Andy to set up a time.
Turnin procedure for this project is to be determined. The due date
is March 19 at 5:00 pm. No slip days are permitted, since we need to
get grades out.