Reference no: EM13887268
In this project, you will implement a Transport Layer protocol to transmit data with Reliable Data Transfer from a client (Sender) to a server (Receiver) in the presence of channel errors and loss. The protocol to be implemented by you is the Go-Back-N protocol. The protocol will be unidirectional in which data is sent in one direction only (client to server) with acknowledgements being sent in the reverse direction (server to client). Only positive ACKs are used. The transmission of packets will be done over UDP (that represents an unreliable network layer channel) using fixed UDP ports.
To implement this protocol, you will write two separate programs called client and server which represent the actions to be executed by the sending and receiving nodes respectively. Both the client and the server will run on orioles.
Packet Formats
The format of a data packet is shown in the figure below. Each data packet contains a 4-byte long header followed by a number of data characters. The header contains 2 fields, each of length 16 bits (2 bytes) as shown in the figure. You must convert the values in these fields into the network byte order when they are transmitted, and convert them back to host byte order when they are received.
The first field of the header is a count of the number of data characters in the packet. This value must be in the range 0 through 80. If the count is 0, then there are no data characters in the packet.
<----------------- 16 bits (2 bytes) ------------------>
--------------------------------------------------------
| Count (no. of data bytes) |
--------------------------------------------------------
| Packet Sequence Number |
--------------------------------------------------------
| Data Bytes | ... |
--------------------------------------------------------
The second field of the header is the packet sequence number. Each packet transmitted by the client is assigned a sequence number in the range 0 through 15.
The format of an acknowledgement packet that is returned from the server to the client is shown in the figure below:<----------------- 16 bits (2 bytes) ------------------>
--------------------------------------------------------
| ACK Sequence Number |
--------------------------------------------------------
Acknowledgements are transmitted (from the server to the client) as separate packets of fixed length, 2 bytes. The first and only field of the ACK packet is the ACK sequence number, which may be in the range 0 through 15. This is the sequence number of the data packet being acknowledged by this ACK.
Once again, you must perform the conversion between network and host byte orders on both the transmitting and receiving ends.
General Actions
The server starts by printing out its port number. It then prompts the user to enter some configuration parameters (see later section for details). It then waits for data packets to arrive from the client.
The client starts by prompting the user to enter the hostname and port number for the server. It then prompts the user to enter the name of the file to be transferred. Next the client prompts the user to enter some configuration parameters (see later section for details).
The client then reads the input file and sends it to the server in a series of packets as described below. The server receives the file and stores it with the name out.txt. When the file transfer is complete, both the client and the server terminate execution.
The client constructs packets by reading lines one at a time from the input file. Each line in the input file contains a sequence of printable characters (no control characters, etc.), with no more than 80 characters on a line. The "newline" character read from the file at the end of each line is also transmitted in the packet and is included within the limit of 80 characters per line. You should note that the "newline" character is not the same as the "null" character used by C as a string terminator. You should not include any "null" characters in the line to be transmitted in a packet.
The client transmits each line to the server in a separate packet. The server receives the packets and puts their data into distinct lines in the output file. You must make sure that duplicate packets are discarded and do not get their data stored in the output file.
When the client is finished transmitting all the lines in the data file, and has received ACKs for all of them, it will send a special last packet called EOT signifying "End of Transmission". This packet will have a Count of 0 and no data characters. It will have a Sequence Number that is the next sequence number that would have been used if this were a valid data packet. It is important that this packet be transmitted only after the client has received ACKs for all transmitted data packets. The server will not transmit an ACK for the EOT packet, and the client will not expect any ACK to be returned for it. The client program can terminate once this packet has been transmitted. When the server receives the EOT packet, it closes the output file and also terminates.
Go-Back-N Protocol
Follow the general description of the Go-Back-N protocol studied in class (also in Figures 3.20 and of your textbook) to design the actions executed by your programs. In addition, use the loop structure for the actions of the client and server described in Lecture Notes Topic 3, Part 3, page 5 of the handout (Go-Back-N: General Implementation).
There are two significant departures from the above protocol in your implementation:
• How you handle the "Call from above" represented by the rdt send(data) function: If the client's window is not full, instead of waiting for the user above to call your protocol machine, you should call a function that reads the next line from the input file and hands it to you as the data to be transmitted in the next packet.
• Checksum: Your packet format does not have a checksum, and your data packets and ACKs are not going to carry a checksum. Thus you will not be doing any checksum computation, nor checking the received packets to see if there are any errors. Thus, the function make pkt will not have a checksum parameter, and you will omit the calls to the functions corrupt and notcorrupt in your code.
Client Actions
Because the client must check for timeouts as well as check for incoming ACKs, it must not block on the read function call if there is no ACK in the input buffer. For this reason, the reading of an incoming packet must be done in a non-blocking fashion. Thus, if there is no incoming ACK available, the read function should not block, but should instead return without reading so you can continue in the loop to check if a timeout has occurred. Use the nonblocking version of the UDP client for your implementation.
The sequence number of successive packets transmitted by the client must range from 0 through 15 and then wrap-around to 0. This is true no matter what window size is being used. It is acceptable if you use a buffer of size 16 to store the queue of unACK'ed packets.
Timeout:
The client needs to start a timer when a data packet is transmitted. A single timer should be used for this purpose (as in the FSM given in your textbook). The semantics of this timer can be tricky, so make sure you understand exactly when the timer needs to be started, cleared, or restarted.
It is sufficient for your purpose to have a simple synchronous implementation of the timer. In this implementation, you can find the current time with a microseconds resolution using the gettime- ofday() function. Pay close attention to the structure returned by this function; both fields of this structure must be used. To start the timer, you can set a timer variable to the time at which the timer should expire (the current time plus the timeout interval). In each loop iteration, you can get the current time and compare with the time stored in the timer variable to decide
whether or not the timer has expired. Be aware of the following pitfalls in using the time structures:• You must use both the seconds and microseconds parts of the time structure; using only one of them is not acceptable.
• You should not combine the values of the seconds and microseconds parts into a single time value. Since each of the parts is a long integer, combining them together may result in an overflow and loss of information, which may cause strange behavior of the client.
• To add, subtract, or compare two time structures, always do the operation on each component (seconds or microseconds) separately, and then deal appropriately with any carry or borrow that results.
Server Actions
The server also runs in a loop; however, it can use the regular blocking version of the server pro- gram. In addition to the server actions for the Go-Back-N protocol, we will introduce one additional function: simulating loss, errors, and delay. We will need to do this because UDP clients and servers running on the same host will almost never see such behavior.
The actions of the server will be as follows:
• Start server loop.
• Wait for packet to arrive from client.
• If packet is received, check if Count field in packet is 0. If it is 0, this signifies an EOT packet, so quit loop.
• If packet is received, but Count field is not 0, this is a regular data packet. In this case, call the simulate function described below to simulate loss, errors, and delay.
• If simulate returns 0, then packet is lost or has errors; discard packet and return to start of loop.
• If simulate returns 1, then packet is correct. Process the packet according to the protocol actions of the Go-Back-N protocol. Generate an ACK if required.
• After ACK is generated, call the function ACKsimulate to simulate ACK loss.
• If the function ACKsimulate returns 0, the ACK is lost, and is not transmitted. If the function returns 1, then transmit the ACK.
• End of loop.