Transport Protocol Project: Sliding Window Implementation

This assignment applies if you are working on the transport protocol project, in a team of maximum two members. Only one team member should submit the assignment. Consult the appropriate document, if you wish to work on the messenger application. The following features are suggested in a particular order. You need not follow this order, but, for full marks, you must implement all the features listed. Please consult the marking scheme at the end of the document.

 

In this assignment, you will extend the sender and receiver from Project Assignment 3 to use a sliding window. If you are familiar with the concept of test driven development (TDD), use it to develop the sliding window class. The sliding window class will likely be common to both the sender and the receiver application.

 

Design and implement a basic sliding window class that extends the simple sequence number counter from Project Assignment 3. At first, the sliding window should only maintain the sequence numbers, including the lower and upper bound sequences in the window, implemented using a go-back-n strategy. Provide operations to advance the window and to return the available space. Recall that a sliding window has a lower and an upper limit represented by sequence numbers. The available space represents the number of sequence numbers by which the upper limit of the window can move forward (the maximum size of the sliding window is limited).

 

It is a good idea to write unit tests for these basic sliding window operations, but this is not mandatory. Implement a circular buffer for the data packets. The responsibility to manage this circular buffer (read or write packets) can be delegated to the sliding window class or to a separate class, depending on your design. It is a good idea to write unit tests for the circular buffer operations, but this is not mandatory.

In the sender: replace the circular counter you used for the alternating bit protocol with the sliding window and circular buffer developed earlier. Keep the receiver as is (using the simple circular counter). Remember to allow a larger than 1 window size in the replies from the receiver, but the behaviour of the receiver should still be simple: save the payload to a file if the payload is received in the right sequence, otherwise ignore the packet.

Test by transmitting one larger file. Use the link simulator but only add delay to the packets, no jitter. Verify that the transfer is correct. Measure the transfer time for different delays. You will report these measurements in your project report.

Design and implementation of Sliding Window Class

Repeat your tests and measurements but this time with jitter. The transfer should still be correct, but this time, expect retransmissions (and thus a lower transfer time) because of packet reordering. Report these measurements too.

In the receiver: incorporate the sliding window in the receiver too. This will allow the receiver to not just drop out of order packets. You may need to add additional features to the sliding window class. For example, you may need to distinguish between sequences received and not yet received in the sliding window. At the sender, likely you will only have unacknowledged sequences in the sliding window.

Repeat and report your tests and measurements from the previous step using jitter. Is there any improvement in the performance of the transfer?
Note that the link simulator can simulate the following conditions: delay, jitter, packet corruption or error (option -e), truncation or cut (option -c), and dropping packets or loss (option -l). Until this point, your implementation can efficiently deal with delay and jitter. For example, perhaps you are not checking for CRC32 until now at the receiver.

Extend your implementation to deal with one more condition simulated by the link simulator, and provide measurements and evidence that the transfer is still correct.

You will note that you are not required to deal with all error scenarios that the link simulator can simulate. For full marks, you should demonstrate three error conditions: delay, jitter, and one more condition of your choice.

 

2.1 Submit:
An archive containing the source code, including unit tests and an appropriate Makefile a Project report that (1) explains how the sender and receiver can be built and how they are executed, (2) provides evidence that the features listed in the marking scheme are correctly implemented, (3) provides the measurements for transferring a sufficiently large file.

 

2.2 Marking scheme:
2 pts The project compiles and generates two executable files, the sender and the receiver. Header unit tests should be incorporated from Project Assignment 1, and all tests should pass.

 

Additional unit tests, if applicable, should also pass.
2 pts The executables correctly transfer files if delay is simulated.
2 pts The executables correctly transfer files if delay and jitter is simulated.
2 pts The executables correctly transfer files if one more error condition is simulated. The report should specify which error should be tested.
1 pt Report: general presentation. How to build and execute the programs. Discuss any assumptions or protocol design choices, such as choice for timer values, etc. Did you use the timestamp field from the header?
2 pts Report: provide and briefly discuss measurements without and with delay on packets.
2 pts Report: provide and briefly discuss measurements with delay and jitter on packets.
2 pts Report: provide and briefly discuss measurements with the third chosen channel condition simulated.