CSE 588 Project 3

Real World Applications

Due midnight, June 4 1999

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

• 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.
• 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?

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

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.

Project 3 code

• Unix Distribution
• Visual J++ 6.0
• Visual J++ 1.1

To run the project, do the following:

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

Turnin

1. Make a file readme.txt in your project directory that contains the following:
   • Your names and e-mail addresses.
   • For each of pruning, congestion control and reliability, a detailed description of your design and implementation; also weather it works or not.
2. Grab the file turnin.class.
3. In your project directory, run the command (from the command line)

   java turnin
   

   (or jview turnin for Visual J++ systems). You will need to be on a machine which is connected to the internet. Be patient. The server is slow and single threaded.