Your assignment is to design and implement a protocol for reliable transport and congestion control, that is, a simplified version of TCP. This assignment consists of two perspectives: reliability and congestion control. We give out the two perspectives at the same time so that you can better organize your design.
Part 2: Design discussion with instructor or TF checkpoint: Nov. 14; Complete code and report due: 1:30 pm, Nov. 17, 2017.
For this assignment, we will usw the "Fishnet" software project infrastructure. Here is some general introduction to Fishnet:
The original Fishnet distribution has limited simulation/emulation of buffering and loss characteristics of physical links. In simulation mode, only loss is simulated, and a link effectively has infinite buffer space. In emulation mode, there is no emulated buffering and loss. Therefore, if you run the emulation on zoo machines, you will almost experience no loss of packets. In order to help you stress test your implementation, we have modified Fishnet to provide simulation/emulation of buffering and loss characteristics of physical links. Please use the links above to download the new code distribution and API documentation.
The following is a summary of changes we have made to Fishnet:
Your job is to design and implement a transport protocol with the following features. For transport packets, use the TRANSPORT_PKT protocol. The packet payload should be a packed object of class Transport.
Connection setup/teardown: A connection is identified by a four-tuple, the combination of a source and destination fishnet address plus a source and destination port value. Our connection state machine is considerably simpler than the one described for TCP. Specifically:
You must support multiple, concurrent connections. We suggest that you define your own transport connection structure, with your node having an array of such structures, one per connection in use. The structure will encode all state associated with a connection, including sequence numbers, buffered data (both sent awaiting acknowledgment and possible retransmission, and received awaiting processing by the application), and connection state (such as established, the SYN has been sent but not acknowledged, etc.).
Reliability and Sliding Window: Each payload packet should be transmitted reliably by using sequence/acknowledgment number field and timeouts and retransmissions.
As usual, you should strive to come up with a design that will inter-operate with other students' nodes. As you do, take the following steps:
These codes will give you visual feedback to help you gauge the progress of a transfer and give us a trace for your turnin. If you print the codes as specified above, a successful connection will appear as a sequence of mostly dot characters marching across your screen.
There are two ways to run your nodes: in the simulator (the 'simulate' mode) or in the emulator (the 'emulate' mode). Suppose your have implemented your "transfer" command with syntax "transfer addr port", where "addr" is the address of the receiver, and "port" is the port the receiver is listening to. The following shows two examples of potentially how to set up the Fishnet environment to run your nodes.
If you use the trawler, here is a topology file that contains only two connected node: two.topo. You can use this file when you run the trawler. Specifically, do the following:
If you use the simulator, there is a sample test script "transfertest.fish" under the "scripts" directory. You can run it using the command "perl fishnet.pl simulate 2 scripts/transfertest.fish". If you would like to know more details about the built-in commands and their syntax, please refer to the documentation at the beginning of CommandsParser.java.
Here are some frequently asked questions and answers for this assignment:
Q: Are all source and destination ports always 1, or are they variable and must be specified in the various commands that you implement?
A: You should support arbitrary port numbers. Please note that the "transfer" command example outlined in the preceding description is only a test scenario suggested for you to test your design.
Q: Are we supposed to support multiple concurrent connections between the same 2 nodes in the same 1-way direction?
Q: Must a server be listening first before a client can connect to it? Do we need a separate command to setup a server?
A: Yes, a server must be listening on a port before a client can connect to it. However, a separate command to setup a server is not strictly required. You may arrange your server to listen on a default port number. However, you're encouraged to implement such a command. Please clearly document your design decision when you submit your assignment.
Q: Should timeout values be constant or variable?
A: Timeout values should be variable. Please refer to the lecture slides for how to determine timeout values.
Q: Do we have to implement slow start?
A: No, slow start is optional.
Q: Should the sender and the reciever both print a packet in their trace
Please submit using classv2 server. Turn in electronic and paper material as follows.
Each part of the project is graded on a 5 point (0-4) scale, multiplied by the weight of the part. The weighted grades from all parts of the project are added together to produce the final grade. There is an extra credit component to this project.
The five point scale is based on how well you show your understanding of the problem, and in case of code how well your implementation works:
0 - nothing turned in
1 - show minimal understanding of the problem / most things don't work
2 - show some understanding of the problem / some things work
3 - show a pretty good understanding of the problem / most things work
4 - show excellent understanding of the problem / everything works
The weights for the parts are:
Transport layer implementation: 1/2 of total grade
Write-up of your design decisions: 1/4 of total grade
Answers to discussion questions: 1/8 of total grade
Print-out of captured output: 1/8 of total grade
Last Update: Oct. 28, 2017 08:56:24 PM -0400