Assignment #3 - Reliable Data Transport Protocol

Due by 11:59pm, Thursday, October 23.

Assignment overview:

In this assignment, you will be implementing the sending and receiving side of a reliable data transport (RDT) protocol. Your protocol should achieve error-free, loss-free, and in-order data delivery on top of a link medium that can lose, reorder, and corrupt packets. Your implementation can follow any variation of the sliding window protocol, e.g., Go-Back-N, Selective Repeat, or the TCP rdt protocol. Since we don't have machines with OS that we can modify, your implementation will run in a simulated environment. This also means that your program should be written in the same programming language as the simulator - C/C++.

The routines you need to implement:

Only unidirectional transfer data is required in this assignment. Of course, the receiver may need to send back packets to acknowledge receipt of data. The routines you need to implement are for the RDT layer at both the sending and receiving side of a data transfer session. These routines will be called by the simulated environment when corresponding events occur. The overall structure of the environment is shown in this picture.

The unit of data passed between the upper layer and the RDT layer is the message, which is declared as:
struct message {
    int size;
    char *data;
};
    
message.size indicates the size of message.data measured in bytes. The reliable data transport protocol requires the data in the receiving node being delivered in order. It does not, however, require the preservation of message boundaries.

The unit of data passed between the RDT layer and the lower layer is the packet, which is declared as:

#define RDT_PKTSIZE 64
struct packet {
    char data[RDT_PKTSIZE];
};
    
This means that the lower layer always delivers packets in 64-byte chunks. Therefore, fragmentation may be necessary if the message passed from the upper layer is too big to fit into a packet.

The routines you need to implement are detailed below. Such routines in real-life would be part of the operating system.

The routines you can call (implemented by the simulated environment):

The routines you can call (implemented by the simulated environment) are detailed below. Such routines in real-life would also be part of the operating system.

The simulated network environment:

The overall structure of the simulation environment is shown in the picture above. There is one and only one timer available at the sender. The underlying link medium can lose, reorder, and corrupt packets. The default one-way latency for this link is 100ms when the link does not reorder the packets. After you compile your code and my code together and run the resulting program, you will be asked to specify the following parameters for the simulation environment.

Helpful hints:

My simulation code and your turn-in:

My simulation code includes 7 files and they can be found at /u/cs257/Resources/assignment3/ on the csug network or at /u/cs457/Resources/assignment3/ on the research/grad network. The simulator is in C++ so your code should be in C/C++ to work with my simulator. The RDT layer is implemented in rdt_sender.cc and rdt_receiver.cc. The current implementation assumes there is no packet loss, corruption, or reordering in the underlying link medium. You will need to enhance them to deal with all these situations. In general, you are not supposed to change rdt_receiver.h, rdt_sender.h, rdt_struct.h, and rdt_sim.cc. For debugging purpose, you may want to add more printouts in rdt_sim.cc. If you do so, definitely remember to test your program with the original rdt_sim.cc before turn-in.

As you can see, the main complexity of the simulator is enclosed in rdt_sim.cc. My intention is that you don't have to read and understand this file to complete the assignment. You can ask for my assistance if you need to understand it for some reason.

You should turn in a README file, the new rdt_sender.cc, rdt_receiver.cc, and any new source files you added for your implementation. If the default makefile doesn't work for you, you should also turn in a new makefile. You should NOT turn in rdt_receiver.h, rdt_sender.h, rdt_struct.h, and rdt_sim.cc because we will use the original versions of those files in grading. Make necessary explanation in your README file for your turn-in.

Testing:

The provided simulation files should compile and run. However, they only work correctly when there is no packet loss, corruption, or reordering in the underlying link medium. Run rdt_sim 1000 0.1 100 0 0 0 0 to see what happens. (Running rdt_sim without parameters will tell you the usage of this program.) In summary, the following are a few test cases you may want to use. Of course, your goal is to make the last test case work. Keep in mind that even if your program works, it may still occasionally report errors due to the limitation of checksumming. Your program, however, should never report errors when there is no packet corruption in the underlying link medium. If your program works for some cases with parameters differing from the above examples, please specify these cases in the README file to get partial credits.

Grading:

Late turn-in policy:

Late turn-ins will be accepted for up to three days, with 10% penalty for each late day. No turn-ins more than three-day late will be accepted.