Base
Before reading this article, please make sure that you have understood the overall idea of falling back N protocol and choosing retransmission protocol.
Parse
Let's assume that 2^n is used as the window. Here n is 3.
According to our assumption, the sender "group" has a total of 8 messages (2^3=8). The sender's number of these messages: 0-7.
When the sender sends No. 0, the receiver returns ACK1 (that is: I received the No. 0 message, please send the No. 1 message!). As a result, this ACK1 is lost due to transmission reasons!
Note that the sender is still sending at this time (because there is no timeout):
the sender sends No. 1 again, and the receiver returns ACK2 this time (that is: I have received the No. 1 message, please send the No. 2 message!). As a result, this ACK2 is lost!
The sender sends No. 2 again, and the receiver returns ACK3 this time (that is, I received the No. 2 message, please send the No. 3 message!). As a result, this ACK3 is lost!
...
until when the sender finishes sending data number 7 .
At this point, the receiver returns ACK0 (that is: I have received the No. 7 message, please send the No. 0 message!). You guessed it right. As a result, this ACK0 is also lost!
Note that at this time, as the receiver, it thinks that it has received all the above information No. 0-7; and he thinks that what he wants to process next is No. 0 of a new group (that is, the total number of language, No. 8) data.
But for the sender, since it has timed out. So it thinks: I didn't receive any ACKs (because according to our assumption these ACKs were all lost). So I have to resend the 0-7 data.
Then, when the sender sends data No. 0, the receiver will naturally use the data that has been received once as a new set of data. This is obviously a repeat reception! is not right.
Why is this? Don't worry, let's look at another example. -
Suppose this time we use 2^n-1. Again we assume n=3 which means our send window size is only 7 bits. The numbers are: 0-6.
Business as usual.
When the sender sends No. 0, the receiver returns ACK1 (that is: I received the No. 0 message, please send the No. 1 message!). As a result, this ACK1 is lost due to transmission reasons!
Note that the sender is still sending at this time (because there is no timeout):
the sender sends No. 1 again, and the receiver returns ACK2 this time (that is: I have received the No. 1 message, please send the No. 2 message!). As a result, this ACK2 is lost!
The sender sends No. 2 again, and the receiver returns ACK3 this time (that is, I received the No. 2 message, please send the No. 3 message!). As a result, this ACK3 is lost!
...
until when the sender finishes sending data number 6 .
At this point, the receiver returns ACK7 (that is: I received the No. 6 message, please send the No. 7 message!). You guessed right. As a result, this ACK7 is also lost!
Note that at this time, as a receiver, it believes that it has received all the above information No. 0-6; and it believes that it is the No. 7 data to be processed next.
But for the sender, it will first judge whether I have received ACK7 (2^3-1), and if I have received it, I will send the next group. If I don't receive it, then I will resend it.
Comparing before and after, the sender 's thinking. The latter is smarter. The clever reason is: the former ACK8 naturally points to the position where the sender should send the next group (this means that this information is unique and accurate: I just want the 0th bit of data. But the same serial number corresponds to different data ). The latter points to an "empty" position. At this time, the data in the eighth digit has no data, which means there is room for judgment! The criterion for judgment is whether ACK7 has received a more vivid image: the original set of information is different from the new set of information. But under the former mechanism, they have the same serial number. And the latter doesn't have that problem!
After reading this, you may not fully understand it. Then look carefully at two examples. And keep figuring it out, and you'll understand after a while.