UDP cont. #
Principles of reliable data transfer #
Expected features
- No bit errors
- No loss of data
Problems
- Bit error
- Data loss
Solutions
- Error detection (checksum)
- Data recovery
So how do we do recovery? We learn from human to human conversation, “pardon?” to recover data loss in the conversation.
Feedback: ACK for positive, NAK for negative.
So the receiver will send an ACK if the packet was received without loss, otherwise it’ll send NAK. Then, from the sender’s perspective it will move on to the next data transmission if ACK is received from receiver. Otherwise, (NAK from receiver) it will retransmit the last data until an ACK is received.
So we have a new problem, what if ACK/NAK is corrupted on the way back?
The sender has no way to find out whether the current packet was successful or not. We can allow the sender to retransmit the data, but it can cause duplicates on the receiver’s side. To avoid and handle duplicates, the sender adds a sequence number to each packet, this way the receiver can discard duplicates.
We have to stop and wait, each time we only transmit one single packet. If we’re only sending 1 packet at a time, when we wait until its successful each time we give it a sequence number, so we actually only need 2 different sequence numbers.
pkt 0… pkt 1… pkt 0… pkt 1… etc
What if the ACK response is corrupted?
If the sender receives the same ACK for the same packet, then that must mean that the last packet was corrupted during transmission. Instead of sending NAK for the current packet, it is equivalent of sending the ACK for the last packet. This tells the sender that the current packet wasn’t successful, and the sender should retransmit.
NAK 1 -> ACK 0;
NAK 0 -> ACK 1;
If the first packet has a problem, then simply no response shows that it had a problem.