5

我目前正在研究相当基础的网络,我目前正在研究可靠传输的主题。我正在使用 Kurrose & Ross 的 Computer Networking 一书,其中两个复习问题如下:

使用selective-repeat/go-back-n 协议,发送方是否有可能收到超出其当前窗口的数据包的ACK?

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

是的,如果窗口大小对于序列号空间来说太大了。例如,接收方获得的数据包数量等于序列号的空间。因此,它的接收窗口已经移动,因此它期待一组新的数据包,其序列号与上一个数据包的序列号相同。接收器现在为每个数据包发送一个 ACK​​,但所有这些数据包都丢失了。这最终会导致发送方对前一组数据包中的每一个都超时,并重新传输每个数据包。接收方认为这组重复的数据包确实是它所期望的新数据包,并且它为每个成功到达发送方的数据包发送 ACK。发送者现在会遇到类似的困惑,它认为 ACK 是确认每个旧数据包都已收到,

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

是否会出现相同的环绕问题,使答案几乎相同?如果没有,是否还有其他情况会导致典型的 GBN 发送方在其窗口之外接收到 ACK?

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

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

与前一个示例相比,这个示例似乎相当无害且不太可能,所以我怀疑它是否正确(但如果我错了,请再次纠正我!)。

4

1 回答 1

1

在实际世界中,一个重复的ACK 延迟到足以掉出窗口又如何呢?

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

根据设计,协议仍然是可靠的,但实现应该能够处理这种窗口外的重复 ACK。

于 2012-11-02T07:31:44.513 回答