Starting from:
$29.99
Assignment 2: Reliable Transport Protocol
Assignment 2: Reliable Transport Protocol
1. Introduction This is the main programming project for this course. You are asked to design and implement a Reliable Transport Protocol (referred to as RTP in the following). In Part1 of the project, you can assume that the network will only delay and potentially duplicate your packets. In Part2, the network can additionally corrupt, reorder or drop your packets. You have significant flexibility in designing RTP. For instance, you can specify any RTP header fields and functionality you want. You can use any checksum, retransmission, or ACKing algorithm you want. For example, you can choose to design an errorcorrecting code (instead of just detecting packet errors). However, you need to satisfy the following constraints: ● RTP should be using a (single) UDP socket to transfer packets over the network. In other words, you are not allowed to use TCP in this project or multiple UDP sockets. ● RTP must be connectionoriented. You can adopt the algorithms that TCP is using for connection establishment and termination or you can design yours. ● RTP must be bidirectional, meaning that data can flow in both directions of an RTP connection at the same time. (This is optional if you are doing the project individually or in a group of two students) ● RTP should be able to detect and recover from duplicate packets. ● RTP has to provide some form of receiver windowbased flow control.
● RTP has to provide bytestream communication semantics (similar to TCP). ● RTP must allow the multiplexing of multiple RTP connections at the same endhost (hint: you may need port numbers at the RTP layer). ● RTP should not make any assumptions about the underlying RTT or capacity of the network. In particular, we will be using a network emulator to limit the underlying network capacity to arbitrary levels and to create variable network delays. ● The maximum RTP packet size should not be larger than 1000 bytes. ● RTP must be able to perform data transfers of arbitrary size. ● RTP has to have a clean Application Programming Interface (API) through which it will be interacting with any higherlayer application. For instance, it is not ok if an application accesses any interval variables of RTP that are not exposed through this API. ● RTP should be efficient in its use of network resources. For instance, it is not acceptable if the sender only transfers one packet per roundtrip time even though the receiver is advertising a larger window size. It is also not acceptable if the sender transmits more packets than allowed by the receiver window because that could create buffer overflows at the receiver.
In part2 of the project, you need to also satisfy the following requirements, in addition to all requirements for part1: ● RTP should be able to recover from packet losses. ● RTP should be able to recover from reordered packets. ● RTP should be able to recover from corrupted packets. ● RTP should perform some form of congestion control (it does not need to be as sophisticated as TCP’s congestion control). Because the Georgia Tech network has excellent performance, we will test your program on a special network (described in Section 4) on which we will introduce various network artifacts (limited capacity, delay, duplication, losses, bit errors, reordering) between the client and server. Your RTP endpoints will be communicating over this private network, encapsulating each RTP packet in a single UDP packet. We recommend that you work on this project with another student. We cannot allow groups of more than two students, unless if you have got the instructor’s approval (but a threestudent group will need to implement additional functionality). You are allowed to use C/C++/Python/Java. Please note that we will test your code on certain CoC machines that run a special network emulator it is not sufficient if your code only works on your laptop.
2. Applications running over RTP We are asking you to write two different applications that run over RTP. These two applications will need to interact with RTP only through an API that you will design (e.g., the RTP interface should allow an application to create a connection, accept a connection, send or receive data, set the local receive window size, close a connection, etc). The first application is the Relational DB application that you have already implemented in the first programming assignment (RDBA). The second will be a simple file transfer application.
2.1 Relational Database Application (RDBA)
In the first programming assignment, you implemented a simple clientserver RDBA application over UDP and TCP. Here, you will reuse the same application but it will be running over your RTP protocol.
2.2 File Transfer Application (FTA)
FTA is a simple clientserver file transfer application. The client will be connecting to a given FTA server and then the client will be able to either download or upload one or more files. The FTA server should be able to support multiple FTA clients (hint: think about multithreading or other ways to support multiple simultaneous RTP connections). The FTA commands should be as follows: FTA Server ● Command line: ftaserver P W to start up the file server. The commandline arguments are: P : the UDP port number at which the FTAserver’s socket is listening. W : the maximum receive window size at the FTAserver (in bytes). FTA Client The FTA client should have an interactive command window that can (sequentially) execute the following commands : ● Command line: ftaclient H:P W to create a reliable connection with the FTA server. The commandline arguments are: H : the IP address or hostname of the FTAserver P : the UDP port number of the FTAserver W : the maximum receive window size at the FTAclient (in bytes) ● Command: get F
to download file Ffrom the server (F should exist in the same directory as the FTAserver executable). The downloaded file at the client must be named “get_F”. ● Command: getpost F G to download file Ffrom the server and at the same time upload file Gto the server through the same RTP connection ( Fand G should exist in the same directory as the FTAserver and FTAclient executables, respectively). The downloaded file at the client must be named “get_F”, while the uploaded file at the server must be named “post_G”. ● Command: disconnect to terminate gracefully the connection with the FTAserver. For both applications, the reliability of the data transfer will be the key criterion for assessing the correctness of your design. Performance will not be an evaluation criterion (unless if your design is clearly inefficient, causing a large transfer delay even for small files). For testing purposes, please make sure that you have stored a binary file (a JPEG image, more than 100KB) at the same directory as the FTA server, and name that file “3251.jpg”.
3. Design Documentation
You need to submit only one design report for both Parts of the project. The RTP design report will need to describe at least the following: ● A high level description of how RTP works along with any special features that you may have designed and implemented. ● A detailed description of the RTP header structure and its header fields. ● Finitestate machine diagrams for the two RTP endpoints. ● A formal description of the protocol’s programming interface (the functions it exports to the application layer, including return values and any error conditions). ● Algorithmic descriptions for any nontrivial RTP functions. Please make sure that you provide a clear answer to (at least) the following questions in your report: ● How does RTP perform connection establishment and connection termination? ● How does RTP perform windowbased flow control?
● How does RTP perform congestion control? ● How does RTP detect and deal with duplicate packets? ● How does RTP detect and deal with corrupted packets? ● How does RTP detect and deal with lost packets? ● How does RTP detect and deal with reordered packets? ● How does RTP (de)multiplex data to different RTP connections at the same host? ● How does RTP support bidirectional data transfers? (if applicable) ● How does RTP provide bytestream semantics? ● Are there any special values or parameters in your design (such as a minimum packet size)?
4. Testing on an Unreliable Network
Before you test your code in the adverse environment, it is always a good idea to first make sure that your design works fine under normal conditions, say on your laptop. For this assignment, we have set up several physical machines to test your code. These machines are configured to delay packets, duplicate packets and to reduce the capacity of the network. This will allow you to test your implementation under adverse conditions. To access these machines, you need to be either on the Georgia Tech network (i.e., using GT machines or connected through the GT WiFi network) or using a Georgia Tech VPN client. Steps to install the VPN client are given by OIT (see http://anyc.vpn.gatech.edu ). Make sure to start and login to the VPN client every time you plan to use the remote machines. In order to access these special machines, you need to ssh as follows: ssh <gt_username @networklabX . cc . gatech . edu where X is an integer between 1 and 8. Remember to use 130.207.107.*/127.0.0.1 as destination or source address (to listen on) in your code. For transferring your code to the remote machines, you may use scp, sftp, or the more userfriendly filezilla , which has a GUI. We have used netem along with tc in order to setup adverse network conditions. If you feel more comfortable testing/debugging on your laptop, we have released the netem/tc commands that we use to setup the adverse network here . This is not required to complete the assignment however.
5. Submission instructions Please turn in welldocumented source code, a README file, and a sample output file called sample.txt. The README file must contain : ● Your name (or names for group projects), email addresses, date and assignment title ● Names and descriptions of all files submitted ● Detailed instructions for compiling and running your programs ● Design Documentation as described in section 3 ● Any known bugs or limitations of your program
1. Introduction This is the main programming project for this course. You are asked to design and implement a Reliable Transport Protocol (referred to as RTP in the following). In Part1 of the project, you can assume that the network will only delay and potentially duplicate your packets. In Part2, the network can additionally corrupt, reorder or drop your packets. You have significant flexibility in designing RTP. For instance, you can specify any RTP header fields and functionality you want. You can use any checksum, retransmission, or ACKing algorithm you want. For example, you can choose to design an errorcorrecting code (instead of just detecting packet errors). However, you need to satisfy the following constraints: ● RTP should be using a (single) UDP socket to transfer packets over the network. In other words, you are not allowed to use TCP in this project or multiple UDP sockets. ● RTP must be connectionoriented. You can adopt the algorithms that TCP is using for connection establishment and termination or you can design yours. ● RTP must be bidirectional, meaning that data can flow in both directions of an RTP connection at the same time. (This is optional if you are doing the project individually or in a group of two students) ● RTP should be able to detect and recover from duplicate packets. ● RTP has to provide some form of receiver windowbased flow control.
● RTP has to provide bytestream communication semantics (similar to TCP). ● RTP must allow the multiplexing of multiple RTP connections at the same endhost (hint: you may need port numbers at the RTP layer). ● RTP should not make any assumptions about the underlying RTT or capacity of the network. In particular, we will be using a network emulator to limit the underlying network capacity to arbitrary levels and to create variable network delays. ● The maximum RTP packet size should not be larger than 1000 bytes. ● RTP must be able to perform data transfers of arbitrary size. ● RTP has to have a clean Application Programming Interface (API) through which it will be interacting with any higherlayer application. For instance, it is not ok if an application accesses any interval variables of RTP that are not exposed through this API. ● RTP should be efficient in its use of network resources. For instance, it is not acceptable if the sender only transfers one packet per roundtrip time even though the receiver is advertising a larger window size. It is also not acceptable if the sender transmits more packets than allowed by the receiver window because that could create buffer overflows at the receiver.
In part2 of the project, you need to also satisfy the following requirements, in addition to all requirements for part1: ● RTP should be able to recover from packet losses. ● RTP should be able to recover from reordered packets. ● RTP should be able to recover from corrupted packets. ● RTP should perform some form of congestion control (it does not need to be as sophisticated as TCP’s congestion control). Because the Georgia Tech network has excellent performance, we will test your program on a special network (described in Section 4) on which we will introduce various network artifacts (limited capacity, delay, duplication, losses, bit errors, reordering) between the client and server. Your RTP endpoints will be communicating over this private network, encapsulating each RTP packet in a single UDP packet. We recommend that you work on this project with another student. We cannot allow groups of more than two students, unless if you have got the instructor’s approval (but a threestudent group will need to implement additional functionality). You are allowed to use C/C++/Python/Java. Please note that we will test your code on certain CoC machines that run a special network emulator it is not sufficient if your code only works on your laptop.
2. Applications running over RTP We are asking you to write two different applications that run over RTP. These two applications will need to interact with RTP only through an API that you will design (e.g., the RTP interface should allow an application to create a connection, accept a connection, send or receive data, set the local receive window size, close a connection, etc). The first application is the Relational DB application that you have already implemented in the first programming assignment (RDBA). The second will be a simple file transfer application.
2.1 Relational Database Application (RDBA)
In the first programming assignment, you implemented a simple clientserver RDBA application over UDP and TCP. Here, you will reuse the same application but it will be running over your RTP protocol.
2.2 File Transfer Application (FTA)
FTA is a simple clientserver file transfer application. The client will be connecting to a given FTA server and then the client will be able to either download or upload one or more files. The FTA server should be able to support multiple FTA clients (hint: think about multithreading or other ways to support multiple simultaneous RTP connections). The FTA commands should be as follows: FTA Server ● Command line: ftaserver P W to start up the file server. The commandline arguments are: P : the UDP port number at which the FTAserver’s socket is listening. W : the maximum receive window size at the FTAserver (in bytes). FTA Client The FTA client should have an interactive command window that can (sequentially) execute the following commands : ● Command line: ftaclient H:P W to create a reliable connection with the FTA server. The commandline arguments are: H : the IP address or hostname of the FTAserver P : the UDP port number of the FTAserver W : the maximum receive window size at the FTAclient (in bytes) ● Command: get F
to download file Ffrom the server (F should exist in the same directory as the FTAserver executable). The downloaded file at the client must be named “get_F”. ● Command: getpost F G to download file Ffrom the server and at the same time upload file Gto the server through the same RTP connection ( Fand G should exist in the same directory as the FTAserver and FTAclient executables, respectively). The downloaded file at the client must be named “get_F”, while the uploaded file at the server must be named “post_G”. ● Command: disconnect to terminate gracefully the connection with the FTAserver. For both applications, the reliability of the data transfer will be the key criterion for assessing the correctness of your design. Performance will not be an evaluation criterion (unless if your design is clearly inefficient, causing a large transfer delay even for small files). For testing purposes, please make sure that you have stored a binary file (a JPEG image, more than 100KB) at the same directory as the FTA server, and name that file “3251.jpg”.
3. Design Documentation
You need to submit only one design report for both Parts of the project. The RTP design report will need to describe at least the following: ● A high level description of how RTP works along with any special features that you may have designed and implemented. ● A detailed description of the RTP header structure and its header fields. ● Finitestate machine diagrams for the two RTP endpoints. ● A formal description of the protocol’s programming interface (the functions it exports to the application layer, including return values and any error conditions). ● Algorithmic descriptions for any nontrivial RTP functions. Please make sure that you provide a clear answer to (at least) the following questions in your report: ● How does RTP perform connection establishment and connection termination? ● How does RTP perform windowbased flow control?
● How does RTP perform congestion control? ● How does RTP detect and deal with duplicate packets? ● How does RTP detect and deal with corrupted packets? ● How does RTP detect and deal with lost packets? ● How does RTP detect and deal with reordered packets? ● How does RTP (de)multiplex data to different RTP connections at the same host? ● How does RTP support bidirectional data transfers? (if applicable) ● How does RTP provide bytestream semantics? ● Are there any special values or parameters in your design (such as a minimum packet size)?
4. Testing on an Unreliable Network
Before you test your code in the adverse environment, it is always a good idea to first make sure that your design works fine under normal conditions, say on your laptop. For this assignment, we have set up several physical machines to test your code. These machines are configured to delay packets, duplicate packets and to reduce the capacity of the network. This will allow you to test your implementation under adverse conditions. To access these machines, you need to be either on the Georgia Tech network (i.e., using GT machines or connected through the GT WiFi network) or using a Georgia Tech VPN client. Steps to install the VPN client are given by OIT (see http://anyc.vpn.gatech.edu ). Make sure to start and login to the VPN client every time you plan to use the remote machines. In order to access these special machines, you need to ssh as follows: ssh <gt_username @networklabX . cc . gatech . edu where X is an integer between 1 and 8. Remember to use 130.207.107.*/127.0.0.1 as destination or source address (to listen on) in your code. For transferring your code to the remote machines, you may use scp, sftp, or the more userfriendly filezilla , which has a GUI. We have used netem along with tc in order to setup adverse network conditions. If you feel more comfortable testing/debugging on your laptop, we have released the netem/tc commands that we use to setup the adverse network here . This is not required to complete the assignment however.
5. Submission instructions Please turn in welldocumented source code, a README file, and a sample output file called sample.txt. The README file must contain : ● Your name (or names for group projects), email addresses, date and assignment title ● Names and descriptions of all files submitted ● Detailed instructions for compiling and running your programs ● Design Documentation as described in section 3 ● Any known bugs or limitations of your program
1 file (12.8MB)
