CSE 588 Project 1

Reliable, Stream Oriented Communications using the Sliding Window Protocol

Due midnight, Friday night, April 23rd

In this assignment, you will use a network simulator to implement and experiment with reliable communication protocols. The simulator will simulate a 'typical' internet link, with variable bandwidth and latency, packet reordering, and drops. These parameters are all configurable.

What you need to implement is a reliable sliding-window communication protocol. Your protocol should be able to correctly handle dropped and reordered packets, and extract a bandwidth as close as possible to the potential bandwidth on the link. The potential bandwidth is defined as:

For Selective Acks

For Go Back N

The default network parameters are:

Paramter	Default value	Allowable values	Flag
MTU	20 bytes	?
Timeout	1 ms	?	timeout=<value>
Bandwidth	1.0 Mbit/sec	1.0 - 100.0 Mbit/sec	bandwidth=<value>
Bandwidth SD	0.2 Mbit/sec	1/5 bandwidth	-no-bandwidth-variation
Bandwidth Walk	0.5	0.0 - 1.0	bandwidth-walk=<value>
Latency	2 ms	1 - 100 ms	latency=<value>
Latency SD	0.5 ms	1/4 latency	-no-latency-variation
Latency Walk	0.5	0.0 - 1.0	latency-walk=<value>
Drop Prob	0.25	0.0 - 0.25	drop-prob=<value>

Turning off latency variation prevents reordering of packets. SD is standard deviation (the quantities are normally distributed). Walk is the tendency of the value's mean to walk with time. 1.0 is the maximum, 0.0 will keep the mean fixed thorugh time.

Provided Code

You are provided with an implementation of a simple stop-and-wait protocol. This is a particularly inefficient protocol (the choice of timeout is particularly poor), and gets somewhere on the order of 3% of the available bandwidth. Nevertheless, you will probably want to use it as a starting point for your sliding window protocol. The major reason for this is that this implementation gives you a bunch of pieces which are really useful for building send and receive algorithms.

The code that you are provided has been divided into the following packages:

• The debug package contains methods for printing out debug messages. You dont have to change this code. However, you might want to use it to print debug messages.
• The timer package manages simulated time. It helps in carrying out operations in zero simulated time.
• The network package provides functionality for sending packets on the network to another node. Again, you dont have to modify any code here.
• The reliability package provides the implementation of the stop and wait protocol. There are two files SAWSender and SAWReceiver that you might want to modify in order to implement the sliding window protocol.
• The application package contains two simple applications - a sender and a receiver that use the reliable sender and a reliable receiver respectively for communication.
• The project1 class reads the command line parameters, sets up a network consisting of two nodes and starts the send and receiver applications.

The code that you would want to modify is SAWSender.java and SAWReceiver.java in order to implement the sliding window protocol. The code is available in two distributions: a zip file for Windows/Visual J++ and a tar file for Unix. The only differences are the CR/LF convention on the source files, and the workspace/makefile setup:

• The Visual J++ version comes with a single workspace containing a project for each package/directory. Also set up in the workspace are the classes to run and the CLASSPATH modifications to find the other packages in the distribution.
  • VJ++ 1.1
  • VJ++ 6.0
• The Unix version comes with a Gnu makefile and a README describing how to set up your environment and run the program.

Compiling and Running

java project1 [seed=] 
              [bandwidth=]               in Mbps
              [bandwidth-walk=]
              [no-bandwidth-variation]
              [latency=]                 in ms
              [latency-walk=]
              [no-latency-variation] 
              [drop-prob=]
              [timeout=]                 in us
              [mtu=]
              [debug=""] 

Turnin

1. Grab the file turnin.class and put it in your project directory.
2. Make a file readme.txt in your project directory that (at the very least) gives your names, describes your algorithm, and tells us how we should run it to see it work. A sample file, which shows what I'm after, is here. Remember: we will be reading this file, and it will benefit you to tell us anything that might be helpful when grading your project. Show us that it works.
3. In your project directory, run the command (from the command line)

   java turnin [directories other than application or reliability or project1 that you want to 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.
   
   IMPORTANT: The turnin script assumes that you have only changed the files in the reliability, application and project1 package. If you have changed files in any other directory, give that directory as a command line argument. Otherwise, we will assume that all the other files are the same as in the original release of the project.

The program also prompts you before going ahead with the turnin. At this point, make sure that you are turning in all the required files. What you get back from turnin is a short receipt listing files and sizes received, the turnin time and the number of slip days used for this assignment.

If you have any problems with turnin, be sure to mail Neil (nspring@cs.washington.edu), and/or post to the email list.