In this assignment, you will explore reliable data transfer mechanism utilizing client-server socket communication. We have introduced RDT 3.0. RDT3.0 is a stop-and-wait protocol that uses alternative bit to realize the reliable data transfer. In this assignment, you will implement client-server communication on two separate processes. Then, depending on your preference, you may implement the RDT sender on the server side and the RDT receiver on the client side or vice versa. The primary function for the RDT sender is to transfer data message (through socket) to the RDT receiver according to RDT 3.0 mechanism. The RDT receiver would ACK the message based on RDT 3.0 mechanism. To simplify the problem, we assume that the sender will always have data to transmit. The data can be defined as a set of phrases such as the days of the week. data=["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"] The sender fetches one of phrases and attaches a proper sequence number to generate a message, which would be sent by the socket to the receiver side. The sender picks the phrases in order. When reaching the last phrase of data set, the sender would go back to the first phrase and continue assembling the message. In this way, the sender would always have data for transfer. As discussed in Chapter 3, the FSM of RDT 3.0 is shown in Figure 1. rdt send(data) udt_rcv(rcvpkt) && sndpkt- make_pkt(0, data, checksum) corrupt(rcvpkt) |I isACK(rcvpkt,1)) I udt send(sndpkt) start timer udt_rcv(rcvpkt) Wait for timeout call Ofromm above for ACKO udt_send(sndpkt) start timer udt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop timer udt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop timer Wait for timeout for ACK1 call 1 f rom udt_send(sndpkt) start timer above udt_rcv(rcvpkt) udt_rcv(rcvpkt) && ( corrupt(rcvpkt) II isACK(rcvpkt,0)) rdt send(data) sndpkt- make_pkt(1, data, checksum) udt_send(sndpkt) start timer Figure 1: RDT 3.0 Sender FSM Because of our assumption of continuous data, the sender no longer needs to wait for data from above. So the FSM can be simplified. The modified FSM is shown in Figure 2. Figure 2.png Figure 2: Modified Sender FSM As you recall, the RDT 3.0 assumes an unreliable channel between the sender and the receiver. However, the socket communication is reliable. To simulate the effect of unreliable packet transmission, we add a naughty receiver function to the receiver side. The FSM of the revised receiver is shown in Figure 3 and the Naughty_Receiver() function is shown in Figure 4. As shown in Figure 4, instead of just sending an ACK with correct sequence number, the Naughty_Receiver function has options to send corrupted ACK, not to send ACK or to send ACK with incorrect sequence number. This function will randomly choose one of the four options (i.e. generate a random number to choose one of the four options with equal chance) to make the sender experience the different error conditions and thus go through all the transitions and actions defined in the RDT 3.0. Note: the checksum is not mandatory in this assignment. When generating the corrupted ACK, the receiver can simply generate a message of corrupted ACK (as long as the sender understands it is a corrupted ACK). Figure 3.png Figure 3: Receiver FSM Figure 4.png Figure 4: Naughty Receiver Function In this assignment, you will use printout messages to indicate the actions of the sender and the receiver. The sample printout messages are shown in the appendix. You can define your termination condition. It could be stop after sending certain number of messages or after fixed number of iterations. You will implement both client-server processes on the same server. You can use C/C++, Java, and Python to program this project. Submission: Please provide source code. You printout messages should show all four options (i.e. each option happened at least once) in the Naughty_Receiver().