CSE 461 Project 3:    Multicast and Real-World Applications

Due March 19, 1998

More config files

• 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

To run the project, do the following:

1. Run java application.project3 config=application/simple.cfg to start the main network
2. Run java application.Nebraska host1 4087 <hostname> (where hostname is the name of the machine from step 1) to start the first client.
3. Run java application.Nebraska host1 4088 <hostname> (where hostname is the name of the machine from step 1) to start the second client.

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 resemble.

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

Objects are represented by a set of attribute values:

Object <id>
X <x>
Y <y>
Z <z>
Color <rgb>
Width <w>
Height <h>

Multicast

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.

Multicast issues

• 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 distant receivers.

  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).

• Reliability: 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 it?

  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 the world?

• Pruning: 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 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 added.

Evaluation

Groups

Design reviews

Turnin