The material for this lab was created by Prof. L. Felipe Perrone based on previous work by Prof. Xiannong Meng (Bucknell University). Permission to reuse this material in parts or in its entirety is granted provided that the credits note is not removed. Additional students files associated with this lab, as well as any existing solutions, can be provided upon request by e-mail to perrone[at]bucknell[dot]edu.
Internet protocols are described in documents called Request for Comments, or RFC, which establish standards and invite people in the community to experiment with and comment on them. UDP is described in RFC 768 from 1980. As you already know, this protocol can be used via the sockets API: the client process creates a SOCK_DGRAM socket, which uses it to transmit messages to a process on the other side of the socket.
The user messages sent on the socket are encapsulated in an UDP datagram, which is in itself encapsulated in an IP datagram, which is then sent to its destination in a frame. UDP is not a reliable protocol. UDP datagrams are simply dropped en route to their destination if their CRC indicates an error, or if a router runs out of buffer space. The dropped datagrams are not retransmitted by protocols in layers below the application layer. This means that the application is responsible for sending acknowledgments, and for dealing with timeouts and retransmissions to guarantee that its data is not lost.
UDP prepends its 8-byte header to an application datagram and passes it to IP. In its own turn, IP prepends its header to the UDP datagram and passes the resulting data to the appropriate outgoing interface. The final datagram is directly added to the output queue of the underlying link, if it is small enough, or else the datagram is fragmented, according to the MTU of the link.
When a send on a UDP socket returns successfully, the datagram (or all its fragments) have been added to the datalink output queue. If there is no space for the datagram or one of its fragments in that output queue cant be sent, the application receives ENOBUFS error message.
Create two programs that communicate bi-directionally using UDP datagrams according to the specifications below. You may certainly use the UDP programs created in our previous lab as a starting point. The source/sink pair in this lab is simpler than the ones we did in our earlier UDP lab.
The source program should also check and report if there is any discrepancy between the message sent and the message received from the sink program. In this part of the lab, the message is not altered, so the one sent should be identical to the one received. Thus we should only see a positive report in this part of the lab.
Create a new program gateway.c which receives a UDP datagram from source and forwards it to sink. With a probability p one byte of the message is altered before the message is sent to sink. For example, if p is chosen as 0.3, then the program should generate a random number r between 0 and 1. If r is less than 0.3, the program alters the value of the first byte in the message by some mechanism of your choice, e.g., adding 1 to the byte. After sending the message to the sink, the gateway waits and receives the message sent back by sink and sends it back to source. Print a message in the gateway if the value is altered (i.e., the randomly generated error value is less than the threshold.) This message helps monitoring the program behavior. Note that when the gateway indicates that the message has been altered, the source program should now detect that the message received from the gateway is different from the message the source sent to the gateway earlier.
The new program gateway.c essentially will act as both a server and a client. It is a server for the source and a client for the sink in Problem 1. Thus you will need to set up the program properly. In particular, the gateway would have to use two ports, one as a server port that receives information from the source and one as a client port that sends information to the sink.
Test the programs by running source, sink, and gateway at the same time, either on the same computer or on different computers. Adjust the value of error rate p so that we can actually see some cases where the received message differs from the sent message on the screen where source is running.
When you're done with the lab problem, make sure you remove unnecessary files, then submit the work to Gitlab.
Congratulations! You just finished this lab.