Udp 返回N协议

我试图在两个独立的客户机和服务器应用程序上实现返回N协议。假设我的序列号必须适合3位，因此2^3=8个最大数字，2^3-1=7个窗口大小

我最初发送我的整个窗口。前两个数据包（0和1）被正确接收。数据包2被丢弃。当接收者收到数据包3到6时，它期望的是2，所以它必须nack它收到的数据包，说它想要2

Sender     Receiver
  0           0
  1           1
  2    (packet dropped)
  3         nack2
  4         nack2
  5         nack2
  6         nack2

当发送方接收到第一个nack2时，它知道已经接收到0和1（通过背驮），并将其窗口向前移动，但它还必须从序列号2开始重新发送其窗口（因此2-3-4-5-6-可能还有7-0）。当发送方接收到第二个nack2时，它已经发送了这些数据包。由于该协议，发送方将再次重新发送其整个窗口，包括2个窗口。现在，接收器可能会收到2个（和其他），但在第二个nack2批中，它将重新收到2个，这是顺序错误的，将不得不nack其预期的数据包，依此类推。我所有这些假设都正确吗

---

如果是的话，在我看来，返回N发送的数据包比停止等待要多得多，尤其是增加窗口大小越多。我没有得到什么？

我发现这个问题的解决方案是简单地使用更多的位来表示序列号，因此具有更大的最大值。如果最大值是2*窗口大小，那么延迟的2不能被误解为正确的确认