CS433/533 Assignment 4: Reliable Transport and Congestion Control

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.

General Introduction to Fishnet

For this assignment, we will usw the "Fishnet" software project infrastructure. Here is some general introduction to Fishnet:

Fishnet with link model

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:

Part 1: Reliable Transport

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:

Part 2: Flow Control and Congestion Control


Running Your Nodes in Fishnet

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?

A: Yes.

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

A: Yes.


Please submit using classv2 server. Turn in electronic and paper material as follows.

Discussion Questions

  1. Diss1a: Your transport protocol implementation picks an initial sequence number when establishing a new connection. This might be 1, or it could be a random value. Which is better, and why?
  2. Diss1b: Our connection setup protocol is vulnerable to the following attack. The attacker sends a large number of connection request (SYN) packets to a particular node, but never sends any data. (This is called a SYN flood.) What happens to your implementation if it were attacked in this way? How might you have designed the initial handshake protocol (or the protocol implementation) differently to be more robust to this attack?
  3. Diss1c: What happens in your implementation when a sender transfers data but never closes a connection? (This is called a FIN attack.) How might we design the protocol differently to better handle this case?
  4. Diss2: Your transport protocol implementation picks the size of a buffer for received data that is used as part of flow control. How large should this buffer be, and why?

Grading guidelines

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