选择重发连续ARQ滑窗协议的有效性

差错控制采用选择重发连续ARQ时，滑窗协议就显得更加完善，接收滑窗就可以开得大一些，但协议的实现也要复杂一些。在这种协议中，允许保留出错帧之后的正确帧，待纠错完毕后再将所有的正确帧顺序地送往主机。

在这一协议中，发送端和接收端都有一个窗口。发送窗口尺寸由开始的0，一直可增至最大的MaxSeq，接收窗口尺寸相对固定。接收端也替每一个在接收窗口内的帧保留一个缓冲器，每个缓冲器使用一位来说明该缓冲器是否已被占用。帧一到达，便通过函数between进行顺序号合法性检查，如果顺序号落在接收窗口中，并且从没有收到过，便接受此帧并存入缓冲器。由于接收窗口尺寸可大于1，因此，凡落在窗口内的帧，不管是否是所期待的那一帧，都要保留，直到所有顺序号小于此帧的帧全部收到以后，才按序向主机交付。

非顺序接收将引起一些顺序接收所不会有的问题。例如，假设顺序号为三位，若仍采用协议5的窗口尺寸，该协议的工作过程为：

①A站向B站送出0～6号帧；

②B站接收，并以Ack0～Ack6应答所有的七个帧；

③由于一个长长的猝发噪声，所有的七个应答全部丢失；

④A站超时，且重发0号帧（最先超时）；

⑤B站在上次全部正确接收后已将接收窗口拨为7、0、1、2、3、4、5，此时帧0到达，它落入窗口内，被认为是一个新帧，就接受它，并且发一个Ack6应答（因7号帧未收到）；

⑥A站收到ACK6后，知道是对所有帧的肯定应答，再拨进发送滑窗，发出7、0、1、2、3、4、5号帧；

⑦B站收到7号帧后，立即检查是否收到0号帧（这时新的0，1，2，…，5帧仍在途中），发现已收到，便将7、0两帧送给上层。

显然，由于B站接收了错误的0号帧，该协议是失败的。(www.xing528.com)

产生这一问题的原因是选择重发连续ARQ在接收端拨进窗口后，一部分新的顺序号与旧的顺序号重叠，后面一批的帧可能重复（如果所有应答丢失），或全新（如果所有应答都收到），但接收端无法对这两种情况进行判断。因此，对于选择重发连续ARQ的窗口大小应比回退n连续ARQ有更大的限制。为了保证接收端拨进窗口以后与原窗口没有顺序号上的重复，窗口最大尺寸应不超过顺序号范围的一半。例如，若顺序号采用4位，则窗口最大尺寸只能为8.这样，如果接收端刚刚收到0～7帧，拨进窗口后则只允许8～15，从而可容易地辨别帧是重发或新发的。一般说来，这时窗口尺寸应为（MaxSeq+1）/2.

另一个有趣的问题是接收端应有多少缓冲器。因为落在窗口外的帧是不被接受的，所以缓冲器数可以是窗口尺寸的值而不需是顺序号的个数。如顺序号为4位，可以只要8个缓冲器，编号分别为0～7，帧i到达后放入缓冲器i（mod8）即可。i与（i+8）在模8时会争用同一缓冲器，但只要窗口尺寸不大于8，它们不可能在同一窗口中。

同理，定时器数也可仅为缓冲器数，而非顺序号的个数。每一缓冲器配一定时器，某定时器超时，其对应缓冲器内的内容便需重发。

在协议5中，应答都采用搭载应答。但若对方没有或少有数据发来，应答就将被耽搁或被阻塞。为此，协议6用一个辅助计时器。该计时器超时将导致一个Hostldle事件发生：在收到帧后，首先启动辅助计时器，如在该辅助计时器规定时间内主机有报文送出，应答便搭载发出，否则就单独发一个应答帧。显然，这种方法更加实用。

由于增加了Nak应答，不再仅靠超时重发，所以一旦发现某帧有误，将立即发一个Nak，并指明出错的帧的序号。为了防止对同一出错帧发出多个Nak，接收端应对给定帧的Nak是否已发出保留记录，如果对FrameExpected的Nak尚未发出，NoNak将为真。即使Nak受损或丢失也无多大妨碍，因发送端超时后一定会将未应答帧重发。Nak的作用主要是提高效率，如果超时时间定得比较“紧”，Nak并无多大作用，但若超时时间较长，Nak则可明显地加快速度。

在协议5中，最先引起超时的总是AckExpected所指的那一帧，因而比较好管理。但在协议6中，由于可以不按顺序接收，故超时的管理比较困难。例如，若发出的是0～4号帧，超时登记表为01234；假设此时0超时，又发了5号帧，1号、2号帧超时，又发了6号帧，这时的超时登记表就为3405126.未来若无情况异常，这7个帧就会按此顺序逐一超时。为了简化，协议6的程序中没有涉及计时管理，而仅用OldestFrame变量指明已超时的一帧。

采用选择重发连续ARQ的滑窗协议的程序如下：

至此，作为学习数据链路控制协议设计原理的范例，已通过由浅入深、由简至繁、由理想条件逐步过渡到非理想的实际情况条件的方式，分析讨论了六个协议，直至协议6才将在协议1中假设的全部理想条件去掉，协议程序也因此逐步完善。但这并不意味着只有协议6才能去掉全部假设条件，其它几个协议也可以去掉假设，而进化成较为完善的协议，如在协议5、协议4中增加单发应答帧、Nak帔的处理以及控制主机流量的方法等等。也可以将滑窗协议的某些方法应用到停等协议中去。在分析讨论这六个协议时，穿插讨论了信息流控制的方法（停等、滑窗）、差错控制方法（停等ARQ，两种连续ARQ）以及简单的协议（通道）效率分析方法。

其实，即使协议6也并非是完善的。仔细考查会发现它的一些问题。例如，若线路发生故障时，发送方会一直地发送（重发）下去，致使上层（主机）既无法再通过它传送其它的帧，也无法停止它的发送而另选其它线路。实际的协议应该对重发次数有所限制，当重发次数超数时，便向上层报告，由上层进行差错恢复或另选其它线路。此外，协议还应有建立连接、终止连接阶段，而不仅有数据传输阶段。因此，在实际应用中，还应做很多工作，或者应尽量选用标准的（现成的）数据链路控制规程，如HDLC、BSC等等。