Objective: Learn about sliding window protocols and the methods needed to ensure reliability.
Deliverables: You must turn in your code on blackboard by 11:59 PM on the part two due date. You must turn in your documentation in by the next lecture after the part two due date. You must demo your client and server meeting requirements for part one on the part one due date, and part 2 by the next lab after the due date. Lab time is expected to be available for these demos, but if there is not sufficient time, you are responsible for arranging a time to complete the demo.
Teams: This project may be done in groups of 1 - 3 students.
Grading: This project is worth 100 points (45 for part 1, 45 for part 2, and 10 for documentation), as described below.
For this lab project we will be using the Mininet virtual network, explained in lab on January 12th. You do not need the project to work in Mininet for the part 1 deadline, but it must work in Mininet for the part 2 deadline.
Please see the using Mininet in CIS457 page for instructions on how to set up Mininet. You can run a defualt topology (all we will need) in Mininet after setting it up by running the command
sudo mn -x. This topology has three nodes: two end hosts and a switch. Starting the simulator should produce four windows. These are the consoles on these three devices, plus a controller (used for advanced programming of switch behavior in software defined networks).
Each of the hosts has a virtual network interface connected to the switch, and can send data to the other through the switch just like a real network. Running wireshark on either host or the switch should work as expected, and running any program on the host should work as expected, with the exception that they can only communicate on the virtual network. Your client and server for this project should work on the two mininet hosts.
You must write a client and server to support file transfer. The client should send to the server a request to initiate a transfer of a specific file. Upon recieving the request, if the file exists, it should be sent to the client. Be sure your program works with all file types, not just text files.
The client and server both must be written in C, C++, Python, or Java (note that Mininet only supports java up to version 7) using UDP datagram sockets.
Due: January 22nd, 2019
The file transfer must work, and must be implemented with a sliding window. Please see the Grading seciton below.
Due: January 28th, 2019
Packet loss, duplication, and reordering must be accounted for. Be sure to think about loss, duplication, and reordering of both data and acknowledgement packets. Please see the Grading section below.
To test your code for part 1, you must make sure file transfer happens correctly. The best command to check if the file transferred correctly is
diff. The syntax to use is:
diff -s file1 file2
To test your code for part 2, you must check if it handles loss, reordering, and duplication. However, you are unlikely to run into any of these happening at random on a small test network, and certain to not run into them at random on the simulator. Instead, we must intentionally cause the simulator to simulate these behaviors.
To simulate loss, we will run commands on the virtual switch, using
netem. Documentation is available at http://www.linuxfoundation.org/collaborate/workgroups/networking/netem. Specifically, to simulate loss, the command to use is
tc qdisc add dev <dev> root netem loss <X.Y%>. Replace <dev> with the network interface you want to simulate loss on. Replace <X.Y%> with a percentage of packet loss to test with. 10% is reasonable for testing. If you are changing your loss percent after already adding it, you will have to replace the word
change. Netem only affects outgoing packets, so, when testing, be sure to run any commands on both of the switch's network interfaces to simulate problems in both directions of the connection.
We will also use
netem to simulate reordering. The specific command to simulate reordering is
tc qdisc add dev <dev> root netem delay <Xms> reorder <Y%>. This will delay Y% of packets by X ms, causing reordering if the packets are originally sent less than Xms apart. Remember as with loss, this command works for only outgoing packets. To simulate reordering in both directions, you must run it on both switch interfaces. You may combine the loss and reordering commands to get both behaviors, with a command like
tc qdisc add dev <dev> root netem delay <Xms> reorder <Y%> loss <Z%>
Duplication can also be simulated using
netem. The specific command to simulate duplication is
tc qdisc add dev <dev> root netem duplicate <Y%>. This will duplicate Y% of packets by X ms. Remember as with loss, this command works for only outgoing packets. To simulate reordering in both directions, you must run it on both switch interfaces. You may combine this command with the others in the obvious way to get a combination of behaviors.
Documentation of your program is worth 10 points. This should be a 2-3 page document describing the design of your program. This should not be a line by line explanation of your code, but should explain the overall structure and logic of the program, as well as what major challenges you encountered and how you solved them.
There will be a total of 100 points, divided as follows:
|File transfer (on error free line) working for text files||10|
|File transfer (on error free line) working for other file types (pdf, jpg, etc)||10|
|Sliding window protocol properly implemented||10|
|Limiting memory to needed data||5|
|Error checking for all inputs||5|
|File transfer works with data loss||5|
|File transfer works with ack loss||5|
|File transfer works with data/ack loss||5|
|File transfer works with data duplication||5|
|File transfer works with ack duplication||5|
|File transfer works with data/ack duplication||5|
|File transfer works with data reordering||5|
|File transfer works with ack reordering||5|
|File transfer works with data/ack reordering||5|