Sender Receiver astPacketAvailable LastPacketRead LastPacketAcked LastPacketsent NextPacketExpected LastPacketRcvd Figure 3: Sliding Window LastPacketAvailable-LastPacketAcked Window S ize packet between LastPacketAcked and LastPacketAvailable must be"buffered-you can either implement his by buffering the packets or by being able to regenerate them from the datafile When the sender sends a data packet it starts a timer for it. It then waits for a fixed amount of time to get the ac lowledgment for the packet. Whenever the receiver gets a packet it sends an acknowledgment for NextPacketE xpected 1. That is, upon receiving a packet with sequence number =8, the reply would be"ACK 8, but only if all packets with sequence numbers less than 8 have already been received. These are called cumulative acknowledgements. The sender has two ways to know if the packets it sent did not reach the receiver: either a time-out occurred, or the sender received"duplicate ACKs If the sender sent a packet and did not receive an acknowledgment for it before the timer for the packet expired, it resends the packet. If the sender sent a packet and received duplicate acknowledgments, it knows that the next expected packet(at least)was lost. To avoid confusion from re-ordering, a sender counts a packet lost only after 3 duplicate ACKs 4 If the requesting client receives a IHAVE from a host, and then it should send a get to that same host,set a timer retransmit the get after some period of time(less than 5 seconds). You should have reasonable mechanisms in your client to recognize when successive timeouts of DaTA or gET traffic indicates that a host has likely crashed Your client should then try to download the file from another peer(reflooding the WHOHAS is fine We will test your your basic functionality using a network topology similar to Figure 4(a). A more complicated topology like Figure 4(b)will be used to test for concurrent downloads and robustness to crashes, as well as for measuring performance in the competition. As suggested by the checkpoints, you can first code-up basic flow control with a completely loss free virtual network to simplify developmen 6.2 Task 2-Congestion control You should implement a TCP-like congestion control algorithm on top of UDP for all Data traffic (you dont congestion control for WHOHAS, IHAVE, and gEt packets). TCP uses an end-to-end congestion control mechaniSender Receiver LastPacketAvailable LastPacketRead LastPacketAcked LastPacketSent NextPacketExpected LastPacketRcvd Figure 3: Sliding Window • LastPacketAvailable − LastPacketAcked ≤ WindowSize • packet between LastPacketAcked and LastPacketAvailable must be ―buffered‖ – you can either implement this by buffering the packets or by being able to regenerate them from the datafile. When the sender sends a data packet it starts a timer for it. It then waits for a fixed amount of time to get the ac￾knowledgment for the packet. Wheneverthe receiver gets a packet itsends an acknowledgment for NextPacketExpected− 1. That is, upon receiving a packet with sequence number = 8, the reply would be ―ACK 8‖, but only if all packets with sequence numbers less than 8 have already been received. These are called cumulative acknowledgements. The sender has two ways to know if the packets it sent did not reach the receiver: either a time-out occurred, or the sender received ―duplicate ACKs.‖ • If the sender sent a packet and did not receive an acknowledgment for it before the timer for the packet expired, it resends the packet. • If the sender sent a packet and received duplicate acknowledgments, it knows that the next expected packet (at least) was lost. To avoid confusion from re-ordering, a sender counts a packet lost only after 3 duplicate ACKs in a row. If the requesting client receives a IHAVE from a host, and then it should send a GET to that same host, set a timer to retransmit the GET after some period of time (less than 5 seconds). You should have reasonable mechanisms in your client to recognize when successive timeouts of DATA or GET traffic indicates that a host has likely crashed. Your client should then try to download the file from another peer (reflooding the WHOHAS is fine). We will test your your basic functionality using a network topology similar to Figure 4(a). A more complicated topology like Figure 4(b) will be used to test for concurrent downloads and robustness to crashes, as well as for measuring performance in the competition. As suggested by the checkpoints, you can first code-up basic flow control with a completely loss free virtual network to simplify development. 6.2 Task 2 - Congestion control You should implement a TCP-like congestion control algorithm on top of UDP for all DATA traffic (you don‘t need congestion control for WHOHAS, IHAVE, and GET packets). TCP uses an end-to-end congestion control mechanism. 10