Implementing a Reliable Data Transport Protocol Phase I: Stop-and-wait Note: We need to implement the functionality in this lab directly in code. Using a package or API that either implements this functionality or a significant part of it is not acceptable. If you are not sure, contact me. 1 Objectives Since you've learned about the socket interface and how it is used by an application; by now, you're pretty much an expert in how to use the socket interface over a reliable transport layer, so now seems like a good time to implement your own socket layer and reliable transport layer! You'll get to learn how the socket interface is implemented by the kernel and how a reliable transport protocol like TCP runs on top of an unreliable delivery mechanism (which is the real world, since in real world networks nothing is reliable). This lab should be fun since your implementation will differ very little from what would be required in a real-world situation. The network communication in the upper two stages was provided through a reliable transfer protocol (TCP/IP). In this stage, you are required to implement a reliable transfer service on top of the UDP/IP protocol. In other words, you need to implement a service that guarantees the arrival of datagrams in the correct order on top of the UDP/IP protocol, along with congestion control. 2 Reliability Specifications 2.1 Introduction and Background Please refer to the lectures' slides for reliable data transfer techniques: Go-back-N, Stop and Wait and Selective repeat. 2.2 Specifications Suppose you've a file and you want to send this file from one side to the other(server to client), you will need to split the file into chunks of data of fixed length and add the data of one chunk to a UDP datagram packet in the data field of the packet. Two methods for RDT should be implemented: 2.2.1 Stop-and-Wait The server sends a single datagram, and blocks until an acknowledgment from the client is received (or until a timeout expires). 2.3 Packet types and fields There are two kinds of packets, Data packets and Ack-only packets. You can tell the type of a packet by its length. Ack packets are 8 bytes, while Data packets vary from 12 to 512 bytes (This is just an example but you're free to choose the header/data size for the packets). Figure 1: Including your packet inside the UDP packet. /* Ack-only packets are only 8 bytes / class ack_packet f short cksum; /* optional bonus part / short len; int ackno; \}; 2.4 Implementation of packet loss To simplify the code, you are sending the packet (from both client and the server) to a Pipe class (I would provide this class). Pipe class may represent a faulty pipe connection, that can drop or delay packets. 3 Work flow between server and client 3.1 Flow of data The main steps are: 1. The client sends a datagram to the server giving the filename for the transfer. This send needs to be backed up by a timeout in case the datagram is lost. 2. The server (child) creates a UDP socket to handle file transfer to the client.(Example from Oracle Tutorial on UDP ) 3. Whenever a datagram arrives, an ACK is sent out by the client to the server. 4. If the pipe (my code) choses to discard the package and not to send it from the server the timer will end at the server waiting for the ACK that it will never come from the client (since the packet wasn't sent to it) and the packet will be resent again from the server. 5. Update the window, and make sure to order the datagrams at the client side. 6. repeat those steps till the whole file is sent and no other datagrams remains. 7. close the connection. 3.2 Handling time-out In stop-and-wait protocol, you need only on time out event. You can implement it using setSoTimeout from https://docs.oracle.com/javase/7/docs/api/javaet/DatagramPacket.html 3.3 Arguments for the client The client is to be provided with an input file client.in from which it reads the following information, in the order shown, one item per line : IP address of server. Well-known port number of server. Port number of client. Filename to be transferred (should be a large file). Initial receiving sliding-window size (in datagram units). 3.4 Arguments for the server You should provide the server with an input file server.in from which it reads the following information, in the order shown, one item per line: Well-known port number for server. Maximum sending sliding-window size (in datagram units). 4 Notes - START SIMPLE. Set the probabilities of loss and corruption to zero and test out your routines. Better yet, design and implement your procedures for the case of no loss and no corruption, and get them working first. Then handle the case of one of these probabilities being non-zero, and then finally both being non-zero. - A good starting point is the following code https://docs.oracle.com/javase/tutorial/ networking/datagrams/clientServer.html - Study DatagramSocket (https://docs.oracle.com/javase/7/docs/api/javaet/DatagramSoc html) and DatagramPacket (https://docs.oracle.com/javase/7/docs/api/javaet/Datagran html)