SR和GBN:窗口外的ACK

Question

我目前正在研究相当基本的网络,我目前正处于可靠传输的主题.我正在使用Kurrose&Ross的计算机网络书,其中两个评论问题如下:

使用selective-repeat/go-back-n协议,发送方有可能接收到落在当前窗口之外的数据包的ACK吗？

对于SR版本,我对这个问题的回答如下:

是的,如果窗口大小对于序列号空间来说太大.例如,接收器获得的数量等于序列号的空间.因此,它的接收窗口已经移动,因此它期望一组新的数据包具有与最后一个相同的序列号.接收器现在为每个数据包发送一个ACK,但是所有这些数据包都会丢失.这最终导致发送方为每个先前的一组数据包超时,并重新发送每个数据包.接收方认为这个重复的数据包集合确实是它所期望的新数据包,它会为成功到达发送方的每个数据包发送ACK.发送方现在遇到类似的混淆,它认为ACK是确认已经接收到每个旧分组,当它们确实是针对新的,尚未发送的分组的ACK时.

我很确定这是正确的(否则,请告诉我!),因为这种情况似乎是为什么窗口大小应该小于或等于序列号空间大小的一半时的经典理由到SR协议,但GBN怎么样？

是否会出现同样的环绕问题,使答案大致相同？如果没有,是否有任何其他情况可能导致典型的GBN发送者在其窗口外接收到ACK？

关于后者,我能想到的唯一例子如下:

GBN发送方按顺序发送数据包A和B. 接收器按顺序接收两者,并发送一个累积ACK覆盖A之前和之前的每个分组,然后发送另一个覆盖B之前和之前的每个分组(包括A).第一个是如此严重延迟,第二个首先到达发送者,导致其窗口滑到A和B之外.当第一个终于到达时,它不必要地确认已经正确接收到A的所有内容,当A是已经在发件人窗口之外.

这个例子看起来相当无害,与前一个例子形成鲜明对比,所以我怀疑它是正确的(但是,如果我错了,请再次纠正我!).

Answer 1

在现实世界中，重复的ACK 延迟足够长以至于从窗口中消失怎么样？

该协议位于发送方和接收方之间，但它无法控制媒体（网络路径）的行为方式。

根据设计，协议仍然可靠，但实现应能够处理此类窗口外重复 ACK。