A Reliable Transport Protocol

Design Report for Networking Project:

Vikram Jain ([e-mail])

Adriano Belfort ([e-mail])

 

Introduction: high level description

This report is a description of a reliable transport protocol that provides bidirectional data flow (client to server and server to client). First the features included are listed; then we have the list of additional input commands; the detailed descriptions of the features; the finite state machines; the API of the protocol and the description of the segment header.

Features included in this project:

• Pipelined Protocol

• Handles Lost Packets

• Handles Duplicate Packets

• Handles out of Order Packets

• Supports Bi Directional Data Transfer

• Uses a Non-Trivial CheckSum Algorithm in the form of Fletcher’s Algorithm

• Other Special Features:

o Multi Threading

o Enable Dynamic Window Resizing

List of Additional (Optional) Input Commands :

• thread t, where t specifies the number of threads the program will use. The default will be set to 1.

o For example fta-client X A P thread 2: will specify there to be 2 threads.

• decreaseSize s, where s specifies how much to decrease the size of the window in the pipeline each time a packet is not received or is corrupted in the pipeline. The default will be 0, and the size of the window will never be less than 1.

o For example fta-client X A P decreaseSize 3: will specify to set the decreasing size at 3.

• increaseSize s, where s specifies how much to increase the size of the window in the pipeline each time a window of packets is successfully transmitted. The default will be 0, and the size of the window will never be greater than W the specified maximum window size earlier.

o For example fta-client X A P increaseSize 3: will specify to set the increasing size at 3.

Please Note :

The rest of the command line inputs will stay the same and their functionality will remain unchanged as well, as specified in the Programming Assignment Description.

Connection setup and termination

The connection is made using a 4-way handshake between client and server. Client and server are modes of operation of the hosts in the protocol. It means that at anytime the user can decide to change the mode, and that represents another agreement between the parts. A client always sends requests to the server and the server replies with information. This design choice facilitates the implementation of the bidirectional transfer feature, as it will be discussed later. After the data is exchanged, the connection terminates just like TCP. The client requests termination of the connections, and an ACK is replied from the server. Then the server sends a request to close the connection too and should receive an ACK back. When the client sends the second ACK, we can set a timer to deallocate resources, because that ACK packet might get lost in its way to the server and the server will send another request to close the connection. The successful delivery of the second ACK triggers the deallocation of resources in the server’s side.

FTA application and bidirectional transfers

The File Transfer Application (FTA) is implemented separately from RTP and offers upload and download of files to and from the server, respectively. The way the application will work is that a file will be specified and that will be broken into packets with headers and transferred packet by packet. Custom user may select the size of each packet. This requires RTP, the protocol that runs under FTA, to provide bidirectional transfer. There is an option of piggybacking data with acknowledgement packets, but it implies a more complicated logic. Instead, the design choice for the bidirectional feature is to swap the roles of client and server (in the finite state machine), because their behavior is well defined. When the transmission of file is finished, they swap roles back.

The switching feature works like TCP’s three-way handshake. First, the client sends a packet to server requesting to change the mode. The server replies with an ack and changes its mode to client. The client receives the ack and changes its mode to server. If the client does not receive the ack from the server, it sends the request again after a timeout. If the server has already changed mode, it sends another ack back, like in a duplicate packet case.

Add pipelining

The file to be transferred is broken into multiple segments and they are sent one right after the other. The way this will work is that when a packet is transmitted it will be put in a list, and when an ack is received it will be removed from the list. After a certain amount of time has passed (timeout) a cron job will run through the list and retransmit packets for which acks were not received. If ack of something not on list received, it is simply ignored.

Have lost and duplicate packets handling

For lost packets, after a certain amount if ack is not received and a packet is on the list (mentioned in previous section) then it will be retransmitted. For duplicate packet received, it is ignored on the receiver side and an ack is sent back otherwise the sender will keep transmitting the packet.

Have corrupted packets handling

Simply an ack is not sent back so the packet will automatically be retransmitted. Corrupted packets are detected using the checksum.

Reordering

As there is as an order part of the packet associated with the transmission,