滑动窗口协议——选择重传协议

选择重传（SR）协议

首先我们通过对GBN协议的分析，可以知道GBN协议本身存在缺陷——GBN在重传的时候回重传很多分组（比如序列号分组n丢失时，需要重传n以及n以后没有确认的分组）。这样就会导致网络中充斥着很多重传的分组，影响分组。
因此，一种改进的机制就是不使用累积确认，采用单个确认，同时我们也不丢弃乱序的分组，将其缓存起来。这时，发送方只需要重传那些没收到ACK的分组。现在对每个分组设置单独的定时器，当某个分组的定时器超时后对其进行重传。

下面考虑SR发送方的事件与动作：

1. 从上层收到数据。当从上层收到数据后，SR检查发送方下一个可用于该分组的序号。如果序号位于发送方的窗口内，则将数据打包并发送；否则就像GBN一样进行处理。
2. 超时。 定时器再次被用来防止丢失分组。然而，现在每一个分组必须由自己的逻辑定时器，因为超时发送后只能发送一个分组。
3. 收到ACK。 如果收到ACK,若该分组序号在窗口内，则SR发送方将那个被确认的分组标记为已接收。如果该序号范围等于send_base,则窗口基序号向前移动到具有最小序号的未被确认的分组处。如果窗口移动了并且有序号落在窗口内的未发送分组，则发送这些分组。

SR的接收方将确认一个正确接收的分组而不管其是否有序。失序的分组将被缓存直到所有丢失的分组（即序号更小的分组）都被收到为止，这是才将一批分组按序交付给上层。
下面考虑SR接收方的事件与动作：

1. 序号在 $[rc{v}_{b}ase,rc{v}_{b}ase+N-1]$ 内的分组被正确接收。在此情况下，受到的分组落在接收方窗口内，一个选择ACK被传回给发送方。如果该分组以前没有收到过，则缓存该分组。如果该分组的序号等于接收方窗口继续耗，则将该分组以及以前缓存的序号连续的分组交付给上层。然后，接收窗口按向前移动分组的编号向上交付这些分组。
2. 序号在$[rcv\_base-N,rcv\_base-1]$内的分组被正确接收到。在此情况下，必须产生一个ACK,即该分组是接收方以前确认过的分组。
3. 其他情况。忽略该分组

• 操作示例：

• SR协议仿真

然而SR也存在有困境，具体情况如下所示

因为接收方不能“看见发送方”采取的动作。接收方所能观察到的是它从信道中收到的以及它向信道中发出的报文序列。就其关注而言，上图的情况时等同的。显然，窗口长度比序列号空间小1时协议无法工作。序列号空间大小与窗口尺寸要满足：${\mathrm{N}}_{\mathrm{S}}+{\mathrm{N}}_{\mathrm{R}}<=2^{\mathrm{k}}$.

最后

以上就是害怕路灯为你收集整理的滑动窗口协议——选择重传协议的全部内容，希望文章能够帮你解决滑动窗口协议——选择重传协议所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。