Reliable Data Transfer (RDT) 2.0

Reliable Data Transfer (RDT) 2.0 protocol works on a Reliable Data Transfer over a bit error channel. It is a more realistic model for checking bit errors that are present in a channel while transferring it may be the bits in the packet are corrupted. Such bit errors occurs in the physical components of a network when a packet is transmitted, propagated, or buffered. In this, we will be assuming that all transmitted packets that are received in the order in which they were sent (whether the they are corrupted). In this condition we ask the user to send ACK (acknowledgement, i.e., the packet that received is correct and it is not corrupted) or NAK (negative acknowledgement i.e. the packet received is corrupted).

In this protocol we detect the error by using Checksum Field, checksum is a value that represents the number of bits in a transmission message. To check the checksum value calculated by the end user is even slightly different from the original checksum value, this means that the packet is corrupted, the mechanism that is needed to allow the receiver to detect bit errors in a packet using checksum is called Error Detection.

This techniques allow the receiver to detect, and possibly correct packet bit errors. In this we only need to know that this technique require that extra bits (beyond the bits of original data to be transferred) be sent from the sender to receiver; these bits will be gathered into the packet checksum field of the RDT 2.0 data packet.



Another technique is Receiver Feedback since the sender and receiver are executing on different end systems, the only way for the sender to learn of the receiver’s scenario i.e., whether or not a packet was received correctly, it is that the receiver should provide explicit feedback to the sender. The positive (ACK) and negative acknowledgement (NAK) replies in the message dictation scenario are an example of such feedback. A zero value indicate a NAK and a value of 1 indicate an ACK.





Sending Side:
The send side of RDT 2.0 has two states. In one state, the send-side protocol is waiting for data to be passed down from the upper layer to lower layer . In the other state, the sender protocol is waiting for an ACK or a NAK packet from the receiver( a feedback). If an ACK packet is received i.e rdt_rcv(rcvpkt) && is ACK(rcvpkt), the sender knows that the most recently transmitted packet has been received correctly and thus the protocol returns to the state of waiting for data from the upper layer.

If a NAK is received, the protocol re-transmits the last packet and waits for an ACK or NAK to be returned by the receiver in response to the re-transmitted data packet. It is important to note that when the receiver is in the wait-for-ACK-or-NAK state, it can not get more data from the upper layer, that will only happen after the sender receives an ACK and leaves this state. Thus, the sender will not send a new piece of data until it is sure that the receiver has correctly received the current packet, due to this behavior of protocol this protocol is also known as Stop and Wait Protocol.





Receiving Side:
The receiver-site has a single state, as soon as the packet arrives, the receiver replies with either an ACK or a NAK, depending on whether or not the received packet is corrupted i.e. by using rdt_rcv(rcvpkt) && corrupt(rcvpkt) where a packet is received and is found to be in error or rdt_rcv(rcvpkt) && not corrupt(rcvpkt) where a packet received is correct.

RDT 2.0 may look as if it works but it has some has some flaws. It is difficult to understand that the bits to ACK/NAK packets are actually corrupted or not, if the packet is corrupted how protocol will recover from this errors in ACK or NAK packets. The difficulty here is that if an ACK or NAK is corrupted, the sender has no way of knowing whether or not the receiver has correctly received the last piece of transmitted data or not.



My Personal Notes arrow_drop_up

Check out this Author's contributed articles.

If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.