Computer Networking - Reliable Data Transfer (RDT)

Principles Of Reliable Data Transfer

Complexity of reliable data transfer protocol will depend (strongly) on characteristics of unreliable channel (lose, corrupt, reorder data?) = Sender, receiver do not know the “state” of each other, e.g.

Reliable Data Transfer Protocol (rdt): Interfaces

• Incrementally develop sender, receiver sides of reliable data transfer protocol (rdt)
• Consider only unidirectional data transfer -But control info will flow in both directions!
• Use finite state machines (FSM) to specify sender, receiver

rdt1.0: Reliable Transfer Over A Reliable Channel

• Underlying channel perfectly reliable = No bit errors / No loss of packets
• Separate FSMs for sender, receiver: Sender sends data into underlying channel , Receiver reads data from underlying channel

rdt2.0: Channel With Bit Errors

• Underlying channel may flip bits in packet = Checksum to detect bit errors

• The question: how to recover from errors:

  1. Acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK
  2. Negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors
  3. Sender retransmits pkt on receipt of NAK

• New mechanisms in rdt2.0 (beyond rdt1.0): Error detection / Receiver feedback: control messages (ACK,NAK) receiver ➔ sender
  

• What happens if ACK/NAK corrupted?

  1. Sender doesn’t know what happened at receiver!
  2. Can’t just retransmit: possible duplicate

• Handling duplicates:

  1. Sender retransmits current packet if ACK/NAK corrupted
  2. Sender adds sequence number to each packet
  3. Receiver discards (doesn’t deliver up) duplicate packet

rdt2.1: Sender, Handling Garbled ACK/NAKs

rdt2.1: Receiver, Handles Garbled ACK/NAKs

rdt2.2: Sender, Receiver Fragments

rdt3.0: Channels With Errors And Loss

• New assumption: underlying channel can also lose packets (data, ACKs)
  = Checksum, seq. #, ACKs, retransmissions will be of help … but not enough

• Approach: sender waits “reasonable” amount of time for ACK

  1. Retransmits if no ACK received in this time
  2. If pkt (or ACK) just delayed (not lost):
     =Retransmission will be duplicate, but seq. #’s already handles this
     =Receiver must specify seq # of pkt being ACKed
  3. Use countdown timer to interrupt after “reasonable” amount of time

• rdt3.0 Sender
  

• rdt3.0 In action
  

• rdt3.0 Receiver
  

• Performance Of rdt3.0

1. rdt3.0 is correct, but ….
   =performance stinks
2. Example: 1 Gbps link, 15 ms prop/net delay, 8K bit packet:
   =Time to transmit packet into channel:
   =U sender: utilization – fraction of time sender busy sending
   =If RTT=30 msec, 1KB pkt every 30 msec: 33kB/sec throughput over 1 Gbps link
3. Network protocol limits use of physical resources!

• Stop-And-Wait Operation
  

GitHub - IlMinCho/CN-RDT

Contribute to IlMinCho/CN-RDT development by creating an account on GitHub.

GitHubIlMinCho

This sender and receiver will communicate with each other through an intermediary server running on gaia.cs.umass.edu, as shown below in Figure, that will function as an unreliable channel connecting this sender and receiver. This sender and receiver will each send messages to the server, and the server will relay (after possibly corrupting, losing or delaying but not reordering) the message to the other side.

In this project, the task involves writing transport-level code for a simple reliable data transfer protocol, specifically an implementation of the rdt 3.0 protocol. This protocol is designed to operate over a channel that may corrupt, lose, or delay messages but will not reorder them. The implementation is close to what is required in real-world scenarios.

The project requires programming a sender and a receiver to reliably transfer the first 200 characters of a text file, using the rdt 3.0 protocol. Unlike the standard rdt 3.0 protocol, the sender in this project will not use rdt_send(data) to send data, nor will the receiver use udt_send(data) to deliver data. Instead, the sender will reliably deliver a file from sender to receiver. Both the sender and receiver will communicate over sockets on the Internet.

The specific task is to transfer the first 200 characters of the Declaration of Independence, available at a given URL, from the sender to the receiver. This process will be executed within the network environment described in the project, employing the rdt 3.0 protocol's sender and receiver finite state machines (FSMs).

Flowchart

Outcomes:

Reference:Prof. Parviz Kermani