Reliable Data Transfer (RDT) 3.0

RDT 3.0 is the last and best version of the Reliable Data Transfer protocol. Before RDT 3.0, RDT 2.2 was introduced, to account for the channel with bit errors which bit errors can also occur in acknowledgments. As the design of RDT 2.2 is a stop-and-wait for protocol. If there is a network issue and the acknowledgment/packet is lost. The sender waits infinitely for it.

How does RDT 3.0 Solve the Above Problem?

RDT 3.0 introduces a timer on the sender side if the acknowledgment is not received within a particular time the sender resends the packet. This method solves the issue of packet loss.

Representation in Finite State Machine

Sender’s FSM

<a href=Reliable Data Transfer (3.0): Sender FSM" width="1030" height="inherit" />

Reliable Data Transfer (3.0): Sender FSM

How it Works?

State-1 (Top-Left): This is the Start state in the sender’s FSM which is called “wait for call 0 from above”. It waits till it receives a message to start from the application layer. In this state, the datagram is created with the sequence number “0” in its header and payload as a message in its body. Finally, the packet is pushed into the network, and execution moves to the next state.

State-2 (Top-Right): This state confirms whether the receiver has received the packet or not. state check that if the received acknowledgment is not corrupt, has the sequence number “0”, and is reached within the time. If these two criteria are satisfied the execution moves to the next state else the state resends the packet.

State-3 (Bottom-Right): This state in the sender’s FSM is called “wait for a call 1 from above”. It waits till it receives a message to start from the application layer. In this state, the datagram is created with the sequence number “1” in its header and payload as a message in its body. Finally, the packet is pushed into the network, and execution moves to the next state.

State-4 (Bottom-Left): This state confirms whether the receiver has received the packet or not. state check that if the received acknowledgment is not corrupt, has the sequence number “1”, and is reached within the time. If these two criteria are satisfied the execution moves to the next state else the state resends the packet.

Receiver’s FSM

<a href=Reliable Data Transfer (3.0): Receiver FSM" width="1062" height="inherit" />

Reliable Data Transfer (3.0): Receiver FSM

How it works?

The receiver’s FSM is the same as RDT 2.2 receiver’s FSM

State-1 (Left): This is the First State in the receiver’s FSM which is called “wait for call 0 from below”. This state whether the received packet has sequence number “0” and is not corrupted. If these conditions satisfy this state creates an acknowledgment packet with the sequence “0” and pushes it into the network which signifies the correct packet is received, the execution moves to the next state else it creates an acknowledgment packet with the sequence “1” and pushes it into the network which signifies the correct packet is not received.

State-2 (Right): This is the First State in the receiver’s FSM which is called “wait for call 1 from below”. This state whether the received packet has sequence number “1” and is not corrupted. if these conditions satisfy This state creates an acknowledgment packet with the sequence “1” and pushes it into the network which signifies the correct packet is received, the execution moves to the next state else it creates an acknowledgment packet with the sequence “0” and pushes it into the network which signifies the correct packet is not received.

Conclusion

RDT 3.0 addressed the limitations of its predecessor, RDT 2.2 , by incorporating a timer mechanism. This enhancement prevents the sender from indefinitely waiting for acknowledgements, thereby improving protocol efficiently and reliability. The finite state machines for both sender and receiver outline the detailed operation of the protocol, demonstrating how RDT 3.0 ensures correct and timely data delivery through a combination of sequence numbers, acknowledgements, and retransmissions.

Frequently Asked Questions on Reliable Data Transfer – FAQs

What is the primary difference between RDT 2.2 and RDT 3.0?

RDT 3.0 introduces a timer mechanism to address the infinite wait issue in RDT 2.2. If an acknowledgement is not received within a specific time, RDT 3.0 retransmits the packet.

How is the timer value determined in RDT 3.0?

The timer value is typically calculated based on the expected round trip time(RTT) of the network. It should be set slightly larger than the RTT to account for network variations.

How does RDT 3.0 ensure reliable data transfer?

RDT 3.0 uses a combination of sequence numbers, acknowledgements, and timeouts to detect and correct errors, ensuring that data is delivered correctly and without loss.