CS455 Introduction to Computer Networks, WSU Vancouver Project : Simulate Pseudo-TCP with UDP In this project you will create a Pseudo-TCP (PTCP) server and Pseudo-TCP client using UDP sockets, implement the reliable data transfer protocol of TCP (more details refer lecture slides page 70-78 of CS455-Transport-A.ppt or textbook). However, connection establishment/release, flow control, congestion control is not necessary. Recall that UDP sockets are connectionless, and do not guarantee the delivery of packets. TCP sockets are connection oriented and provide reliable data transfer. Your PTCP client and server implementation will be using the UDP sockets available and provide reliability as in TCP. For example, you will read from a file of size greater than 10 MB and send it as multiple packets of size 100 bytes (e.g., MSS = 100) each to the arbitrator code provided to you. YOU SHOULD RECORD DOWN ANY CHANGE EVERY TIME YOU CHANGE THE CODE OF ARBITRATOR. ARBITRATOR TAKES THE PACKET FROM THE CLIENT AND SENDS IT TO THE SERVER. IT WILL RANDOMLY SELECT PACKETS FROM THE FLOW AND DROP IT. IT COULD ALSO SEND THE PACKETS IN OUT OF ORDER. IT ALSO TAKES THE ACK PACKETS AND DROPS THEM RANDOMLY AND COULD ALSO REORDERS BEFORE SENDING BACK TO THE CLIENT. Each packet sent will have a sequence number and you will keep track of the sequence numbers of the packets sent. You need to maintain a timer to keep track of the sent time for the packets, see when the timer expires and retransmit the unacked packets. The client will receive the acknowledgment packets (ack) and do the necessary updating depending on the policy in use. For the reliable data transfer protocol, you need to maintain n number of packet details for retransmission. It will print the sequence number of the packets it sent and also the sequence number of the packets that were acknowledged. The client will send a file to the server in N(e.g., constant window size) packets of size 100 byte (e.g., MSS=100, it should be an adjustable parameter) each. It will receive the acks and decide the next packet to be sent. The server receives the packet and sends an ack as required. Print the sequence number of the packets. It will print the sequence number of the packets it received. Both window size N and MSS should not be hard- coded, in other words, they are adjustable parameters. In each experiment, you may keep them constant for simplification (e.g., congestion control is NOT necessary). The purposes of this project: to become familiar with TCP’s reliable data services and UDP protocols. Learning file-handling operations is also a part of this project. Logistics You need write this program in C under Linux. What to turn in: 1. Printed listings of your code, Makefile, and README files are to be turned in during class on the due date. CS455 Introduction to Computer Networks, WSU Vancouver As in previous projects, the README file should contain complete instructions for compiling and running, and report on some experiments that you ran and your insight into the additional features required. 2. All files are also to be submitted electronically by using the “submit” command you have used in the Project 1 submission, prior to midnight (11:59PM) on the due date During the week following the due date, if necessary, you will each need to schedule an individual appointment with the TA to demonstrate your TCP implementation and to describe its operation. Specifications You are to create an Pseudo TCP client that 1. Takes input value of the port of arbitrator to send the file. 2. Opens a file to send and reads it in blocks of MSS bytes. 3. Opens a connection to the arbitrator. 4. Send N number of packets after adding the Sequence number to the packets. The sequence number starts at 1. (instead of random for simplification) 5. Gets the acks and does the necessary actions. Keeps track of all the packets that were dropped. 6. Implements the required timers, and maintains an adaptive time-out interval. Upon time-out, it will have to retransmit the required packet(s). Your Pseudo TCP server does the following 1. Takes input value of the port on which it will receive the file from arbitrator. 2. Waits on a specific port for a file from a client. 3. Accepts a connection and gets the file in bytes of MSS. 4. Reads the sequence number and sends an ack back. 5. Keeps track of the missing packets and writes to the file in proper order. 6.Keeps track of the out-of-order packets and, using a buffer, stores them. 7. Has a fixed buffer size of N(the window size). YOU CANNOT STORE ALL THE PACKETS AND THEN WRITE TO A NEW FILE AT A TIME. Acknowledgement for the packet should be cumulative (refer to slides 70-78)! Development Hints Start with basic UDP and try implementing one of the methods with server and client on the same machine Implement the reliable data transfer without the arbitrator in between. CS455 Introduction to Computer Networks, WSU Vancouver Implement the reliable data transfer using the arbitrator in between. Try for Pseudo TCP server and Pseudo TCP client on different machines. Test your program Test the efficiency of your Pseudo TCP server and client under different network environments. The client will send a file to the server in N(e.g., constant window size) packets of size 100 byte (e.g., MSS=100, it should be an adjustable parameter) each. Test the total packet transmission time, including packet retransmission, under different ACK random drop rate (ACK is from TCP server to TCP client) 10% to 90% with 10% incremental step. The tips for modifying arbitrator to adjust the ACK drop rate are given in the appendix. REMEMBER YOU should have detailed record of what you have changed in arbitrator. Adjust the data drop rate (Data is from TCP client to TCP server) in arbit.c from 10% to 90% with 10% incremental step. Record down the total data transmission time, including data retransmission time. Plot the packet transmission time vs. different ACK drop rate and different data drop rate in a 3-D mesh plot. Please submit this graph in your project report. Advice 1.The work YOU submit MUST be the result of the efforts of yourself. Do not copy code from others. See the course syllabus for the punitive actions that result from any cheating/plagiarism violations. 2.Start early. This will help you to debug your application if your face some problems. 3.Ask questions EARLY. The TA is available to help you several hours per week, but not for extensive help at the last minute. Grading To summarize, grading will strictly follow the policy below: Totally 100 points, late submission will cause 20% penalty each day; 75 points of the grade will be for working code. Your demonstration of your TCP server and Client to the TAs will be part of this grade. 15 points for the README file, test report file and make file. 10 points of the grade will subject to your code’s organization & modularity, readability & consistency, and robustness (bug-free). In other words, these points are rewarded according to your programming skills. If the program can not be compiled or run in Linux, 0 points will be awarded; If the source code is stolen from Internet, 0 points will be awarded; Appendix: How to use the Arbitrator. CS455 Introduction to Computer Networks, WSU Vancouver The Arbitrator code takes the machine on which the client runs and the machine on which the server is running as input values. To run this you must first compile the code as cc –o arbit arbit.c To run the code type arbit <client machine> <server machine> 8600 8500 Client arbitrator Server 8650 8550 The arbit code works as follows. Arbitrator opens different processes to handle the packet transmissions in both directions. It listens on port 8600 and 8550 for the information. Once it gets some packets on port 8600, it decides if the packet should be forwarded or dropped. If it has to be forwarded it just sends it back to the port 8500. YOU CAN CHANGE THE DECISION POLICY TO TUNE THE DROP RATE. Your client will send packets on port 8600 and your server will receive them on port 8500. The server creates an acknowledgement for the packets and sends it back to the arbitrator on the port 8550. This packet is sent back to your client on port 8650. The client decides the next packet to be sent based on the implementation. The client code needs multi threading capability or else it won’t be able to send and receive packets at a time (remember the recvfrom call is blocking receive). EMail the TA or go to her office if you have any problems with this code. Try not to change this code. If you have to change it write what all changes you had to make in the comments file. TIP-I: If you have binding errors change the port numbers in #define and it should work. TIP-II: The specific code lines of arbitrator you need to change are from L127 to L148 (Client-to-Server direction) and from L227 to L247 (Server-to-Client direction). “Ran” is a random number generated inside the while-loop. The sanity check on the variable of “ran” is to decide whether to forward the packets or not. YOU can use the modulo operation to fit the sanity check into different drop rates. IF YOU HAVE TO ABRUPTLY CLOSE THE PROGRAM, MANUALLY CHECK IF ALL PROCESSES ARE CLEANED.