使用Go-Back-N协议的序列号有多less位

我是Stack Overflow(软件开发人员)正在尝试通过networking课程。 我有一个家庭作业问题,我想有一个理智的检查。 这是我得到的。

问:

使用Go-Back-N协议,使用3000千米长的T1中继线传输64个字节的帧。 如果传播速度是6微秒/ km,那么序列号应该有多less位?

我的答案:

对于这个问题,我们需要做的是奠定基础知识。 我们试图find的是我们应该使用Go-Back-N的最大序列号的大小。 为了解决这个问题,我们需要弄清楚一次有多less数据包可以放进我们的链路,然后从这个数字中减去一个。 这将确保我们在链路中不会同时有两个具有相同序列号的数据包。

链接长度:3000km速度:6微秒/ km帧大小:64字节T1传输速度:1544kb / s( http://ckp.made-it.com/t1234.html )

传播时间= 6微秒/公里* 3000公里= 18,000微秒(18毫秒)。 将1544kb转换为字节= 1544 * 1024 = 1581056字节传输时间= 64字节/ 1581056bytes /秒= 0.000040479秒(0.4ms)

那么如果我们把18ms的传播时间除以0.4ms的传输时间,我们将会看到我们将能够一次将(18 / 0.4)45个数据包填充到链路中。 这意味着我们的序列号应该是2 ^ 45位长!

我用这个方向正确吗?

谢谢,迈克

为了解决这个问题,我们需要弄清楚一次有多less数据包可以放进我们的链路,然后从这个数字中减去一个。 这将确保我们在链路中不会同时有两个具有相同序列号的数据包。

我不同意这个推理。 没有两个具有相同序列号的分组的点将通过不在窗口之外发送帧的协议实体来实现。 您应该区分窗口大小N和序列号范围。 对于只有5帧的窗口使用32位序列号没有问题,但这当然不是最佳的。

如果一个方向的传输时间是18ms,那么你将有一个RTT,往返时间为18ms +接收端处理时间+ 18ms。 我不知道在这种情况下哪些处理时间值是合理的,所以让我们假设为零。 这给了36ms的RTT。 这意味着,从发送帧的angular度来看,它将(在最好的情况下)在获得该帧的确认之前花费38ms。 这决定了决定窗口大小时有多less优秀数据的上限。 如果窗口尺寸较大,则只会填充发送端的发送缓冲区,不会影响吞吐量。 可能还有其他因素(如接收端的缓冲区大小)会进一步限制窗口,但由于没有给出任何信息,我们假设接收端有无限制的缓冲区等。

为了达到最佳(吞吐量)性能,窗口应该足够大,以便发送者可以连续发送38ms。 T1速度是每秒193000字节。 每帧64字节对应于每秒3015.625帧。 0.038次,3015.625次,114.59375次。 也就是说,在38ms内,你可以发送114帧。 因此,可以select稍大于理论最大值(例如115-120)的窗口大小(使得限制因子是物理链路而不是窗口大小)。 序号范围必须大于窗口大小,在这种情况下,128是最接近的最大值。

所以你的问题的答案是,在这种情况下你需要最less7位的序列号。 另请参阅此处的交互式回退-n Java小程序。