Programming Assignment 2: Reliable Data Transport Protocol

This assignment counts for 13% of the total module mark. Failure in this assessment may be compensated for by higher marks in other components of the module. The purpose of the assignment is the implementation of a reliable data transport protocol to understand the principles behind such protocols and to better understand TCP. It partly assesses the following learning outcome:

The assignment is due Friday, 20 November 2020, 17:00.

Late submissions are subject to the University standard system of penalties. (cf. Section 6 in Code of Practice on Assessment)

In this assignment you will implement a reliable data transport protocol. You can use any operating system when programming this assignment.

Submission Instructions

Overview

In this programming assignment, you will be writing the sending and receiving transport-level code for implementing a simple reliable data transfer protocol. You have the choice between two versions of the assignment:

For the basic assignment you cannot get a mark >80%.

Your implementation will differ very little from what would be required in a real-world situation.

Since we do not have standalone machines (with an OS that you can modify), your code will have to execute in a simulated hardware/software environment. However, the programming interface provided to your routines (i.e., the code that would call your entities from above (i.e., from application layer) and from below (i.e., from network layer)) is very close to what is done in an actual UNIX environment. Stopping/starting of timers are also simulated, and timer interrupts will cause your timer handling routine to be activated.

Note that you do not need a network connection to run this assignment, so you can do it pretty much on any machine you would like.

The code you will write
The methods you will write are for the sending entity (Sender.java) and the receiving entity (Receiver.java). Only unidirectional transfer of data (from sender to receiver) is required. Of course, the receiver side will have to send packets to the sender to acknowledge (positively or negatively) receipt of data. Your code is to be implemented in the form of the methods described below. These methods will be called by (and will call) methods that have already been written which emulate a network environment. The overall structure of the environment is shown in Figure 1:

The unit of data passed between the application layers and your protocols is a message, which is declared as: 

public class Message {
   private String data;
}

This declaration, and all other data structure and emulator classes are already constructed. Your sending entity will thus receive data in 20-byte chunks from the application layer; your receiving entity should deliver 20-byte chunks of correctly received data to the application layer at the receiving side.

The unit of data passed between your routines and the network layer is the packet, which is declared as: 

public class Packet{
   private int seqnum;
   private int acknum;
   private int checksum;
   private String payload;
}

Your class methods will fill in the payload field from the message data passed down from the application layer. The other packet fields will be used by your protocols to insure reliable delivery, as we've seen in the lectures.

You will have to write methods for two classes as detailed below. As noted above, such procedures in real-life would be part of the operating system, and would be called by other procedures in the operating system.

Sender.java:

Output(message),
where message is an instance of the class Message, containing data to be sent to the receiver.
This method will be called whenever the application layer at the sending side (Sender.java) has a message to send. It is the job of your protocol to insure that the data in such a message is delivered in-order, and correctly, to the receiving side application layer.
Input(packet),
where packet is an instance of the class Packet.
This method will be called whenever a packet sent from the receiver-side (i.e., as a result of a udtSend() being called by a Receiver method) arrives at the sender-side. packet is the (possibly corrupted) packet sent from the receiver-side.
TimerInterrupt()
This method will be called when the timer of the sender expires (thus generating a timer interrupt). You'll probably want to use this method to control the retransmission of packets. See startTimer() and stopTimer() below for how the timer is started and stopped.
Init()
This method will be called once, before any of your other sender-side methods are called. It should be used to do any required initialization.

Receiver.java:

Input(packet),
where packet is an instance of the class Packet.
This method will be called whenever a packet sent from the sender-side (i.e., as a result of a udtSend() being called by a Sender method) arrives at the receiver-side. packet is the (possibly corrupted) packet sent from the sender-side.
Init()
This method will be called once, before any of your other receiver-side methods are called. It can be used to do any required initialization.

Software Interfaces

The methods described above are the ones that you will write. The following methods have already been written. These methods can be called by your methods:

startTimer(increment),
where increment is a double value indicating the amount of time that will pass before the timer interrupts.
To give you an idea of the appropriate increment value to use: a packet sent into the network takes an average of 10 time units to arrive at the other side when there are no other messages in the medium. Thus, in expectation the RTT (round trip time) is about 20 time units. A good value for increment is twice that much.
stopTimer(),
for stopping the timer.
udtSend(packet),
where packet is an instance of the class Packet.
Calling this method will cause the packet to be sent into the network, destined for the other entity.
deliverData(message),
where message is an instance of the class Message. With unidirectional data transfer, you would only be calling this within Receiver.java.
Calling this method will cause data to be passed up to the application layer.

The simulated network environment

A call to the method udtSend() sends packets into the medium (i.e., into the network layer). Your Input() methods are called when a packet is to be delivered from the medium to your protocol layer.

The medium is capable of corrupting and losing packets. It will not reorder packets. When you compile your classes and the pre-coded classes together and run the resulting program, you will be asked to specify values regarding the simulated network environment:

Different Options for the Assignment

You have the choice of implementing either the Stop-and-Wait or the Go-Back-N version of this assignment.

For both versions you have to write some methods for Sender.java and Receiver.java. You will find a link to a skeleton of these files and also the other supporting java classes at the end of this document.

Stop-and-Wait version

You are to write the methods, Output(),Input(),TimerInterrupt() and Init() for Sender.java, and Input() and Init() for Receiver.java. Together these will implement a stop-and-wait unidirectional transfer of data from the sender-side to the receiver-side. Your protocol should be similar to rdt3.0, which we discussed in the lectures. It is your choice whether you want your protocol to be NACK-free or whether you want to use ACK and NACK messages. For a NACK-free protocol you can e.g. implement the rtd3.0 sender on slide 3.50 together with the rdt2.2 receiver on 3.46.

You should choose a very large value for the average time between messages from sender's application layer, so that your sender is never called while it still has an outstanding, unacknowledged message it is trying to send to the receiver. I'd suggest you choose a value of 1000. You should also perform a check in your sender to make sure that when Output() is called, there is no message currently in transit. If there is, you can simply ignore (drop) the data being passed to the Output() routine.

Make sure you read the ``helpful hints'' for this assignment following the description of the extra credit assignment.

Go-Back-N version

You are to write the methods, Output(),Input(),TimerInterrupt() and Init() for Sender.java, and Input() and Init() for Receiver.java. Together these will implement a Go-Back-N unidirectional transfer of data from the server-side to the receiver-side, with a window size of 8.

I would STRONGLY recommend that you first implement the basic assignment (Stop-and-Wait) and then extend your code to implement the extra-credit assignment (Go-Back-N). Believe me - it will not be time wasted! However, some new considerations for your Go-Back-N code (which do not apply to the Stop-and-Wait protocol) are:

Output(message),
where message is an instance of the class Message, containing data to be sent to the receiver-side.
Your Output() method in Sender.java will now sometimes be called when there are outstanding, unacknowledged messages in the medium - implying that you will have to buffer multiple messages in your sender. Also, you'll now need buffering in your sender because of the nature of Go-Back-N: sometimes your sender will be called but it won't be able to send the new message because the new message falls outside of the window.
Rather than have you worry about buffering an arbitrary number of messages, it will be OK for you to have some finite, maximum number of buffers available at your sender (say for 50 messages) and have your sender simply abort (give up and exit) should all 50 buffers be in use at one point. In the ``real-world,'' of course, one would have to come up with a more elegant solution to the finite buffer problem!
TimerInterrupt()
This method of Sender.java will be called when the timer expires (thus generating a timer interrupt). Remember that you've only got one timer, and may have many outstanding, unacknowledged packets in the medium, so you'll have to think a bit about how to use this single timer. In fact, we discussed how to do this in the lectures.

Helpful Hints and the like

Evaluation

You should make sure that your code compiles. Code which does not compile will receive at most 20%.

We will assess your assignment using the following questions:

Stop-and-Wait Protocol
Go Back N Protocol:
Other Characteristics:

Code

Here are the JAVA files that you'll need:

Here is a zip-achive of all java files:

This zip file also includes Testing.java, which is a command line interface for testing your protocol. The following is an example for using this interface for sending 20 mesages over a channel with loss probability 0.1, corruption probability 0.2, delay between messages 1000, trace level 2, and seed 256:
java Testing 20 0.1 0.2 1000 2 256

Some notes: