Out of the various
The stop-and-wait protocol relies on acknowledgments (ACKs) for the exchange of packets. To elaborate, the sender sends out one
Since the protocol requires a sender to not send a packet without receiving the last packet's acknowledgment, there are a few rules that the protocol entails, as shown below:
Sender side | Receiver side |
It send only one packet at a time. | It receives and consumes the received packet. |
It sends the next packet if and only if the ACK of the prior packet is received. | It sends an ACK to the sender once a packet is received. |
If a timeout occurs (for noisy environments), it sends the current packet again. |
While the stop-and-wait protocol is incredibly simple to implement if assuming a noiseless channel, there are a host of issues when a noisy channel is introduced.
For instance, if a packet gets lost before it reaches the receiver, the receiver waits for an infinite amount of time (or until it's timeout) for the packet. Subsequently, this causes the sender to wait for an infinite amount of time for the ACK, so no further packets are sent. If a timeout is implemented on the sender side, the sender sends out the same packet at timeout.
Additionally, suppose the channel is noisy, and an ACK gets lost before it can reach the sender. In that case, the sender waits for an infinite amount of time (or until timeout) for the ACK and never sends out the next packet, and sends out the same packet at timeout again.
Finally, there also exists the scenario where there's a delay in the ACK reaching the sender. In this case, a timeout occurs on the sender's side, and the sender re-transmits the same packet. The receiver gets two of the same packets (increased redundancy), and the sender gets two of the same ACKs.