CIS 410/510 Introduction to Networks
Fall 1998

Program B: ARQ

Handed Out: 9 November 1998
Due: 4 December 1998 in class by 10am


Overview

You will write the ARQ file transfer protocol on top of a UDP socket interface. The protocol should operate as described in the book, with the corrections made in the lecture notes.

Supplied Code

I will supply you with code for a client and a server, along with some supporting files, in the class directory in:

   /cs/classes/cis510networks/program2
Together, these will form a framework for this assignment. These files are primarily the same as in Part A. The significant additions include:
client.cc & server.cc These files include an additional argument (-w) that lets you set the client and server window size.
packet.h Defines additional packet formats
error.h Defines additional error messages
plain.h, plain.cc, stop-and-wait.h, stop-and-wait.cc Includes my solution code for Part A. You can use your own code or this code as a reference for similar functions in Part B.
arq.h & arq.cc Defines the ARQ file transfer protocol class. You should implement the methods defined in this class and add any variables you need to the class definition
cache.h & cache.cc Defines a packet cache. You will need to implement this class so the client and server can cache a windows' worth of packets. Use any implementation you prefer for the cache. Note that the server technically only needs to keep track of which packets have been received, without caching their contents. However, using the same cache code for both server and client will simplify this assignment.

See the files for more details. Files are commented and marked with TBD to indicate where you should make changes.

Packet Formats

The ARQ protocol should transfer packets using the data and ack types, and do the same three-way handshake as for Part A using close and closeack. In addition, new packets are defined for an opening handshake. Before sending the file, the client executes:

Meanwhile, the server executes the following:

After the opening handshake, the client begins sending data packets beginning with the sequence number listed in the open packet. For example, undergraduates start with data packet number 1.

Undergraduates do NOT need to write the ARQ code to handle sequence number wrapping (i.e. the sequence number will never wrap around to zero).

For this entire assignment, all short timers should be 10000 microseconds and long timers should be 1 second.

Error Checking

You should check for the same errors as in Part A. In addition, you should check for the following error: For all of the above errors, ignore the packet and print out the associated error message. In addition, you should check for the following errors: For these errors, you should print an error message using error.h and immediately exit. If your code is functioning correctly, these errors should never occur. See cache.cc for an explanation of how to check for these errors.

You should also report system call errors using perror() and immediately exit the program.

Extra Graduate Requirements

Graduates are also required to choose a random sequence number for the opening handshake (between 0 and 65535) and to implement sequence number wrapping. So, if the window spans the values [65533,3], the protocol should continue to operate correctly.

Output

Your server program should print out the file being transferred, along with any error messages that occur. The client should only print out any error messages that occur. Grading will be based on exactly matching the output of a solution program that runs as described in this handout. You can find sample output in the class directory so you can test your program's abilities.

Deliverables

Things you should turn in on paper:

You should turn in a printout of any source code files you change. You should put comments in your code so that I can understand what you have written. You should also turn in a printout of sample output using a battery of tests that you have designed to test all cases given above. Organize the printouts so that I understand what each piece of paper is demonstrating.

Things you should turn in online:

Submit all the source code (including the files I have supplied). Do not submit any object code. Use the submit program documented in the Assignments section of the class web page.

Grading

Grading will be based on a battery of tests based on the scenarios outlined above and judged on strict compliance to the output your program produces. Borderline grades can be pushed up or down a level by the quality of the documentation.