CSE 461 Project 1

Reliable, Stream Oriented Communications using the Sliding Window Protocol

Due 5:00 pm, Thursday, 29 October 1998

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

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

    The command-line usage is

    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=""] 
    

    so working inside Visual J++ you will have to set the class to run as project1 and specifiy any arguments in the entry field until Project/Settings/Debug. The flag arguments are described above, the <seed> argument is an integer that will seed the random number generator. If omitted then the seed will be drawn from the current time. By specifying a seed, you can get consistent behavior of the network, which will make bug-tracking much easier. I strongly recommend that when tracking bugs you find a seed that causes your bug and then fix it until you fix the problem. When you think your program works, try a few runs without specifying the seed.

    Turnin

    To turn in project 1, do the following:
    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 turnin program prompts you for the student ID for the "first" student in the group. I don't really care whose SID you use, but make sure that if you submit more than once you keep using the same SID to identify the group. As long as you use the same SID you can submit as many times as you like. All turnins are saved, but unless we have some reason to do otherwise we will only look at the last one.

    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 Amit (amit@cs.washington.edu), and/or post to the email list.

    ---

    amit@cs.washington.edu