Home

The Protocol

The data link protocol that was simulated was Continuous-RQ (Selective Repeat). In this protocol, there can be up to a specified number (window size) of frames outstanding between the client and the server at any time. This was the major challenge in constructing the simulation. The protocol also makes use of the CRC-16 checksum. The CRC-16 algorithm was performed on the entire data frame and the resulting remainder bit pattern was appended onto the existing frame in it’s trailer. This frame was then sent across an artificial network and the checksum was verified on the remote side. In order to simulate an unreliable network, a gremlin function was used to corrupt approx. 50% of the frames sent across the network. The gremlin function would randomly select the sequence number, payload length, data or remainder portions of the frame and change the values to a random value in their respective accepted ranges. A key part of the protocol is the acknowledgement system. Upon receipt of each frame from the client, the server verifies the checksum in the trailer of the frame. If the frame is invalid an immediate negative-acknowledgement (NACK) is sent to the client requesting the retransmission of that frame. If the frame is valid, then subsequent frames are checked until the window size has been reached, at which point, if all frames are valid an acknowledgement (ACK) is sent, indicating the previous ‘window-size’ frames were successfully received and verified.

The Implementation

The simulation was constructed using Java and made extensive use of it’s socket functionality. A server socket was set up on the server side, to which a client socket on the client side could connect. This allowed for communication between the two programs. In order to make use of a full-duplex connection, four threads were used: two on the server side and two on the client side, each for transmitting and receiving data respectively. The receiving threads continuously polled the socket’s input streams and interpreted the data that was being transmitted from the other side. The receiver thread would then instruct the transmitter thread based on the data it had received. For example, when the simulation begins, the client’s transmission thread begins sending frames to the server. The server’s receiver thread then examines the frames and verifies that no corruption has occurred using the CRC-16 algorithm. If corruption has occurred, it immediately instructs the transmission thread to send a NACK frame containing the sequence number of the corrupted frame. In turn, the receiver thread on the client side receives this NACK frame and instructs the client’s transmission thread to resend this frame. Alternatively if the first ‘window-size’ of frames the client transmits are valid, the server’s receiving thread instructs the server’s transmission thread to send an ACK frame containing the last sequence number that was received. This frame is then taken by the receiver on the client side who can then instruct the transmission thread to begin sending new frames once more. The handling of the NACK signals is more complex than described above however and is best illustrated with an example. Consider a window size of 5 frames. Once the client sends these five frames [1 to 5], if the server notices that frame number 2 is corrupt, it will request a retransmission of the frame. However as the name suggests, the Selective Repeat Protocol requires only the corrupted frame to be resent. Thus all of the other of the initial five frames must be buffered by the server to avoid them too requiring a retransmit, even though they may or may not be corrupt. Once frame two is retransmitted, other frames can be verified and further NACKs and retransmits can occur, but at each stage only the frames which are known to be corrupted are retransmitted.