Project #4: Reliable Communication over an Unreliable Network CS 352 Internet Technology Released: March 22nd, 2022; Due: April 8th, 2022 Instructions 

Please read these instructions carefully before you begin. 1. You must work on this project in teams of 2. 2. You are free to discuss the project on Piazza or through other means with your peers and the instructors. You may refer to the course materials, textbook, and resources on the Internet for a deeper understanding of the topics. However, you cannot lift solutions from other students or from the web including GitHub, Stack Overflow, or other resources. Do not post this project to question-answering services like Chegg. All written and programmed solutions must be your teams original work. We run sophisticated software to detect plagiarism and carefully monitor student answers. If you are in doubt, please ask us. 3. You cannot post your solutions to this project on your personal GitHub page or on other web services hosting class materials. 4. For each question in the project report, please be clear and concise. Vague and rambling answers will receive zero credit. 5. For the report question on collaboration, please include anyone you discussed the project with, and also any resources you consulted to learn how to solve this project, including URLs of pages visited on the Internet. Please be specific about the aspect of the project that you got help with. You must be thorough and as complete as possible here. It is mandatory to answer this question. 6. Weencourageyoutostartearlyandgetthebulkoftheworkforthisprojectdonetheweek(s) before it is due, rather than keeping it until the submission date. 7. If you have any questions or clarifications on the project, please post them on Piazza or contact the course staff. We are here to help. 1 Overview In project 4, you will implement a reliable sender using an unreliable UDP socket. There are two programs provided in the project 4 archive: sender.py and receiver.py. You will only modify sender.py. The sender.py program is a UDP sender that must implement the techniques of reliable delivery that we discussed during lecture to upload a file to the receiver. Specifically, you will implement reliability based on stop and wait and cumulative-ACK-based selective repeat. The receiver.py program is a UDP receiver that is attempting to download a file transmitted by the sender over a lossy channel that may drop packets, ACKs, or both. We will test reliability by checking that the receivers version of the file matches exactly with the senders version of the file (there are a few samples provided in the project archive for your testing and reference). Unlike the prior projects, this project uses python3. Step 1: Lets take it for a spin! The sender and the receiver are equipped with command line flags to customize their operation. $ python3 sender.py --help usage: sender.py [-h] [--port PORT] [--infile INFILE] [--winsize WINSIZE] optional arguments: -h, --help --port PORT --infile INFILE --winsize WINSIZE Window size to use in pipelined reliability show this help message and exit receiver port to connect to (default 50007) name of input file (default test-input.txt) You can specify which file you wish to upload through the --infile flag, the localhost port to which the file must be uploaded (i.e., where the receiver is listening), and other flags. By default, the file test-input.txt will be uploaded to localhost port 50007. The receiver is more complex, with command line flags to control the packet and ACK losses that are simulated in the communication. $ python3 receiver.py --help usage: receiver.py [-h] [--pktloss {noloss,everyn,alteveryn,iid}] [--ackloss {noloss,everyn,alteveryn,iid}] [--pktlossN PKTLOSSN] [--acklossN ACKLOSSN] [--ooo_enabled] [--port PORT] [--outfile OUTFILE] optional arguments: -h, --help show this help message and exit --pktloss {noloss,everyn,alteveryn,iid} Emulated loss behavior on packets (default every n packets) 2 --ackloss {noloss,everyn,alteveryn,iid} Emulated loss behavior on ACKs (default noloss) --pktlossN PKTLOSSN --acklossN ACKLOSSN --ooo_enabled --port PORT --outfile OUTFILE n for pkt loss behaviors (only if loss specified) n for ack loss behaviors (only if loss specified) enable out of order data buffering (default false) receiver local port to bind to (default 50007) name of output file (default test-output.txt) By default, the channel between the sender and receiver drops every 3rd packet that is transmit- ted to it (i.e., --pktloss everyn --pktlossN 3) but does not drop ACKs (i.e., --ackloss noloss). By default, the receiver writes its downloaded output into the file test-output.txt. Step 1.1: Test without any drops To test the file upload/download without any packet drop, run the following commands on separate terminals: python3 receiver.py --pktloss noloss and python3 sender.py By doing this, we are configuring the receiver to not drop any data (packets or ACKs); instruct- ing sender.py to simply push the bytes in the input file test-input.txt through the UDP socket to the receiver, and the receiver to write the downloaded outputs into test-output.txt. You will see many helpful prints on both the sender and the receiver. At the sender: [S] Transmitting file test-input.txt [S]: Sender socket created Transmitted Seq: 5 Transmitted Seq: 7 Transmitted Seq: 15 Transmitted Seq: 23 Transmitted Seq: 31 Transmitted Seq: 39 Transmitted Seq: 47 Transmitted Seq: 55 Transmitted Seq: 63 Transmitted Seq: 71 Transmitted Seq: 79 ACK: 2345367 Len: 8 Msg: msg 10 Transmitted Seq: 87 ACK: 2345367 Len: 8 Msg: msg 11 [S] Sender finished all transmissions. 3 ACK: 2345367 ACK: 2345367 Len: 2 Len: 8 Msg: 88 Msg: msg 1 2 3 4 5 6 7 8 9 ACK: 2345367 ACK: 2345367 ACK: 2345367 ACK: 2345367 ACK: 2345367 ACK: 2345367 ACK: 2345367 ACK: 2345367 Len: 8 Len: 8 Len: 8 Len: 8 Len: 8 Len: 8 Len: 8 Len: 8 Msg: msg Msg: msg Msg: msg Msg: msg Msg: msg Msg: msg Msg: msg Msg: msg The input file is broken up into packets each of which contains 8 bytes. Each message is trans- mitted with an application layer protocol format that includes a sequence number, ACK number, message length, and the actual application bytes. At the receiver, you will see: [R]: Receiver socket created Received Seq: 5 ACK: 2345367 Transmitted Seq: 235347 ACK: 7 Received Seq: 7 ACK: 2345367 Transmitted Seq: 235347 ACK: 15 Received Seq: 15 ACK: 2345367 Transmitted Seq: 235347 ACK: 23 Received Seq: 23 ACK: 2345367 Transmitted Seq: 235347 ACK: 31 Received Seq: 31 ACK: 2345367 Transmitted Seq: 235347 ACK: 39 Received Seq: 39 ACK: 2345367 Transmitted Seq: 235347 ACK: 47 Received Seq: 47 ACK: 2345367 Transmitted Seq: 235347 ACK: 55 Received Seq: 55 ACK: 2345367 Transmitted Seq: 235347 ACK: 63 Received Seq: 63 ACK: 2345367 Transmitted Seq: 235347 ACK: 71 Received Seq: 71 ACK: 2345367 Transmitted Seq: 235347 ACK: 79 Received Seq: 79 ACK: 2345367 Len: 8 Msg: msg 10 Transmitted Seq: 235347 ACK: 87 Len: 0 Msg: Received Seq: 87 ACK: 2345367 Len: 8 Msg: msg 11 [R] Writing results into test-output.txt [R] Receiver finished downloading file data. You can check that the file was received intact by comparing the input and output files. In this project, we can use the diff command to do this. Run diff test-output.txt test-input.txt If you see a blank output, that means the files are exactly the same. The transmission was fully correct! Step 1.2: Test with packet loss Unfortunately, real networks can experience loss of packet data, and UDP sockets dont provide a reliable interface over lossy networks. Lets try our file upload/download over a lossy network. On separate terminals, run 4 Len: 2 Len: 0 Len: 8 Len: 0 Len: 8 Len: 0 Len: 8 Len: 0 Len: 8 Len: 0 Len: 8 Len: 0 Len: 8 Len: 0 Len: 8 Len: 0 Len: 8 Len: 0 Len: 8 Len: 0 Msg: 88 Msg: Msg: msg Msg: Msg: msg Msg: Msg: msg Msg: Msg: msg Msg: Msg: msg Msg: Msg: msg Msg: Msg: msg Msg: Msg: msg Msg: Msg: msg Msg: 1 2 3 4 5 6 7 8 9 python3 receiver.py and python3 sender.py By default (i.e., with no options to receiver.py), the communication channel deterministi- cally drops every 3rd packet that is transmitted by the sender. The sender.py program happily thinks it has sent all the data correctly. However, there are mistakes in the downloaded file. The content corresponding to messages 1, 4, 7, and 10 are only in the input, but not in the output! $ diff test-output.txt test-input.txt 0a1 >msg 1 2a4 >msg 4 4a7 >msg 7 6a10 >msg 10 You will see from the receiver.py output that the receiver indeed detects these losses through the gaps in the sequence numbers. Specifically, there are messages that say fresh data creating seq space hole, corresponding to data received after dropped sequence numbers: [R]: Receiver socket created Received Seq: 5 ACK: 2345367 Transmitted Seq: 235347 ACK: 7 Received Seq: 15 ACK: 2345367 [R] Fresh data creating seq space hole Transmitted Seq: 235347 ACK: 23 Received Seq: 23 ACK: 2345367 Transmitted Seq: 235347 ACK: 31 Received Seq: 39 ACK: 2345367 [R] Fresh data creating seq space hole