In this project, you will build a simple reliable transport protocol, “BEARDOWN-TP”. Your protocol must
provide in-order, reliable delivery of UDP datagrams, and must do so in the presence of packet loss,
delay, corruption, duplication, and re-ordering. After this project, you should be able to
Handle Python socket programming with ease
Recognize and use class and functions in Python
Handle unexpected conditions in network
Write programs that follow stop-and-wait algorithm
Have some experience in test-driven development
There are a variety of ways to ensure a message is reliably delivered from a sender to a receiver. We will
provide you with a reference implementation of a receiver (which you must use) that returns a
cumulative ACK whenever it receives a data packet. This is further explained with an example later. Your
job is to implement a sender that, when sending packets to this receiver, achieves reliable delivery using
a stop-and-wait strategy.
I have prepared the starter code for you. If you are using our Mininet-MIS VM, open your terminal and
in your home directory (~) type the following code:
git clone https://github.com/weichen-ua/MIS543_Proj3.git
This will download the starter code and put them in ~/MIS543_Proj3. There are several files in the
directory. In these files, I have provided the framework of the solution and the code is described in
details below. You just need to complete and submit Sender.py on Blackboard.
Note: Your VM needs to connect to the Internet for the above command to work. If you are not
connected, try to use “sudo dhclient -v" to request a new IP for your VM. If you are not using our
Mininet-MIS VM, you can also download the starter code from https://github.com/weichen-
ua/MIS543_Proj3.
What you can and cannot share: For this project, you can and are encouraged to share testing
techniques (including ways you test the network conditions). What you cannot share is your code for
testing and Sender.py.
1 This project borrowed heavily from a project in UC Berkeley CS 168.
MIS 543 – Business Data Communications Networking
Project 3: Reliable Transport Protocol
Protocol Description
Our simple protocol has four message types: start, end, data, and ack. start, end, and data messages all
follow the same general format.
start|||
data|||
end|||
To initiate a connection, send a start message. The receiver will use the sequence number provided as
the initial sequence number for all packets in that connection. After sending the start message, send
additional packets in the same connection using the data message type, adjusting the sequence number
appropriately. Unsurprisingly, the last data in a connection should be transmitted with the end message
type to signal the receiver that the connection is complete. Your sender should accept
acknowledgements from the receiver in the format:
ack||
An important limitation is the maximum size of your packets. The UDP protocol has an 8 byte header,
and the IP protocol underneath it has a header of ~20 bytes. Because we will be using Ethernet
networks, which have a maximum frame. size of 1500 bytes, this leaves 1472 bytes for your entire packet
(message type, sequence number, data, and checksum).
The angle brackets (“”) are not part of the protocol. However, you should ensure that there are
no extra spaces between your delimiters (“|” character) and the fields of your packet. For specific
formatting details, see the sample code provided.
Receiver Specification
We will provide a simple receiver for you; the reference implementation we provide will also be used for
grading, so make sure that your sender is compatible with it.2 The BEARDOWN-TP receiver responds to
data packets with cumulative acknowledgements. Upon receiving a message of type start, data, or end,
the receiver generates an ack message with the sequence number it expects to receive next, which is
the lowest sequence number not yet received.
You can assume that once a packet has been acknowledged by the sender, it has been properly
received. The receiver has a default timeout of 10 seconds; it will automatically close any connections
for which it does not receive packets for that duration.
Sender Specification
The sender should read an input file and transmit it to a specified receiver using UDP sockets. It should
split the input file into appropriately sized chunks of data, specify an initial sequence number for the
2 We will test your senders in a variety of scenarios: e.g., packet loss or data corruption. Just because your sender is
compatible with the receiver in one test environment does not ensure a perfect score! Your sender must be capable
of handling all scenarios outlined in this document.
MIS 543 – Business Data Communications Networking
connection, and append a checksum to each packet. The sequence number should increment by one for
each additional packet in a connection. Functions for generating and validating packet checksums will be
provided for you (see Checksum.py). Your sender must implement a reliable transport algorithm using a
Stop-and-Wait strategy. Your sender must be able to accept ack packets from the receiver. Any ack
packets with an invalid checksum should be ignored.
Your sender should provide reliable service under the following network conditions:
Loss: arbitrary levels; you should be able to handle periods of 100% packet loss.
Corruption: arbitrary types and frequency.
Duplication: you could see a packet any number of times.
Delay: packets may be delayed indefinitely (but in practice, generally not more than 10s).
Your sender should be invoked with the following command:
python sender.py -f -a -p
Some final notes about the sender:
The sender should implement a 500ms (0.5s) retransmission timer to automatically retransmit packets
that were never acknowledged (potentially due to ack packets being lost).
Your sender should roughly meet or exceed the performance (in time and number of packets
required to complete a transfer) of a properly implemented stop-and-wait based BEARDOWN-
TP sender.
Your sender should be able to handle arbitrary message data (i.e., it should be able to send an
image file just as easily as a text file).
Any packets received with an invalid checksum should be ignored.
Your sender MUST NOT produce console output during normal execution; Python exception
messages are ok, but try to avoid having your program crash in the first place.
We will evaluate your sender on correctness, time of completion for a transfer, and number of packets
sent (and re-sent). Transfer completion time and number of packets used in a transfer will be measured
against our own reference implementation of a stop-and-wait based sender.
To begin with, just focus on the simple case where nothing bad ever happens to your packets. After you
have that case working, you can consider how to handle packet loss.
Testing
You are expected to write test cases for your own code to ensure compliance with the project
specifications. To assist you, we've given you a simple test harness (TestHarness.py). The test harness is
designed to intercept all packets sent between your sender and the receiver. It can modify the stream of
packets and check to ensure the stream meets certain conditions. This is very similar to the grading
script. that we will use to evaluate your projects.
MIS 543 – Business Data Communications Networking
We have provided two test cases (BasicTest and RandomDropTest) as examples of how to use the test
harness. These test cases send the README file using the specified sender implementation to the
specified receiver implementation, either passing all packets through the forwarder unmodified or
dropping random packets. They both then verify that the file received by the receiver matches the input.
To run a test using this test harness, do the following:
python TestHarness.py -s YourSender.py -r Receiver.py
where "YourSender.py" is the path to your sender implementation, "Receiver.py" is the path to the
receiver implementation. Inside TestHarness.py, you need to modify the function "tests_to_run" at the
top of the script. to include any test cases you add.
Passing the basic test cases we provide is a necessary but not sufficient condition for doing well on this
project; there are still some edge cases that they do not cover. You should think about what these edge
cases might be and write appropriate test cases to cover them.
What to Turn In
For this project, turn in Sender.py to Blackboard.
Grading
Your project will be graded by a script. which is similar to the TestHarness and test agains several
conditions. These grades will be determined automatically from the results from the script. Therefore,
test your code thoroughly and make sure they pass the following grading criteria before you submit it.
1 pt Correct
Submission
Submitting substantial code that shows a good effort attempting all
aspects/functionality of the project.
1 pt Basic Test Your sender should work well under perfect network condition. It should pass
the test of BasicTest in TestHarness.py
1 pt Basic Speed Your sender should roughly meet or exceed the performance (in time and
number of packets required to complete a transfer) of a properly implemented
stop-and-wait based BEARDOWN-TP sender.
2 pts Random Drops Your sender should work well under network condition where packets are lost.
It should pass the test of RandomDropTest in TestHarness.py
2 pts Corruption Your sender should work well under network condition where packets have
corruptions.
2 pts Duplication Your sender should work well under network condition where packets have
duplications.
1 pt Delay Your sender should work well under network condition where packets can be
delayed (up to 1s).