Homework 4: a reliable transport protocol (part one)

In this homework, we implement a reliable transport protocol over an unreliable link.

Setting Up Network Emulation

We'll use the netem facility of Linux traffic control to create an artificially high-latency, slow, lossy and/or reordering connection between two programs on your local machine.

To configure a latency of 100 ms +/- 10ms, and a 10% packet loss rate, 25% reordered packets and a rate of 1 mbps, on the lo interface (localhost):

sudo tc qdisc add dev lo root netem delay 100ms 10ms loss 10% reorder 25% 50% rate 1mbit

To remove this configuration, use

sudo tc qdisc del dev lo root

Assignment Description

The homework template, available in the class repository  includes two programs that implement a file transfer service: receive.c and send.c. These are used as follows:

./receiver <port> > <filename>

to start listening for an incoming file on port <port>. Note how stdout is redirected into a file here. And

./sender <hostname/address> <port> <file>

to send the contents of <file> to the receiver listening on the specified host and port. Only file contents need to be transferred - no need to worry about file names, or other metadata. Your program will be tested with a variety of settings: high/medium/low latency, high/low/no losses, high/medium/low rate and reordering and judged on:

• correctness. Every file transfer must complete, and deliver the full file with identical contents.
• speed on lossless links. The protocol should achieve close to the ideal capacity on a loss-less link. If payload is 1450 bytes, on a 200 ms r/t latency link, ideal capacity is 1450/0.2 bytes/second.
• speed on lossy links. The protocol should achieve close to ideal capacity on this lossy links as well. Here, ideal capacity is (1-loss_rate)*1450/rtt, where loss_rate is in the range 0..1.

For this assignment, you may (but don't have to) restrict yourself to a single outstanding packet; send one packet, then wait for the ACK. In the next assignment, we will extend this to a window of outstanding packets.

Restrictions

The programs may take no additional parameters beyond those specified above, and cannot use TCP or other existing reliable transport protocol implementations for the transfer. The file transfer must take place using UDP packets only - no other means of communication, but you may put anything you want inside said UDP packets!

Some things we will test

To test correctness, we will, among other things, test the following scenarios:

• Normal sender -> receiver with lossless low/high-latency link. Do programs exit cleanly, and does sender produce accurate output?
• Normal sender -> receiver with low/high loss low-latency link. See above.
• Sender killed midway through transfer: does receiver eventually exit, and exit cleanly?
• Receiver killed midway: does sender eventually exit cleanly?
• Sender killed midway, and restarted: does the receiver handle this gracefully?
• Sender killed midway, then restarted with a different file. Does receiver handle this gracefully?

Suggestions

• Start simple: three-way handshake SYN/FIN, sequence numbers and acks, with a single outstanding data packet. Hard-coded time-out. Without the handshake, the last three tests will be difficult.
• Add RTT estimation using the EWMA method.

Turn-in

Turn in your assignment using this link. Make sure the turn-in folder includes a Makefile. "make" should build both sender and receiver. If your preferred language doesn't build a binary, include instructions for how to run it.