现讨论协议的设计原理。对双工停等协议（一位滑窗协议）加以改进，可得一个新的协议（协议5），称为管道协议。在该协议中，采用回退n连续ARQ法进行差错控制，但纠错方法不采用NAK，而采用超时重发，其顺序号可以有多个二进制位。为适应滑窗协议可连续发送的特点，可以去掉（协议4中的）主机可以提供无限数据的假设。这样，当主机有报文要发送时，它将产生一个中断事件，使HostReady变量置位。而且，为了满足流量控制要求及有效地利用滑窗，其规定发送窗口尺寸为MaxSeq，CCP必须有相应措施防止主机给予过多的待发报文。过程EnableHost和DlsableHost便是起这一作用的。
该协议的接收窗口尺寸为1，发送窗口维持的窗口大小为2n-1，即MaxSeq，而不是MaxSeq+1（2n），这与差错控制和应答有关系。对于顺序号3位，MaxSeq=7的情况，其工作过程为：
①发送端发出第0帧至第7帧（窗口宽为23=8）；
②帧0～7的应答（应答号ACK=7）回到发送端；
③发送端又发出另外的第0帧至第7帧；
④帧7的应答又回到发送端。问题是：假若第一个应答丢失，接收端将无法判断第二个8帧是重发的帧还是新发的帧。如果第二次发的第0帧出错，后面的7帧也都被接收端丢弃，并以上一次正确收到的帧的序号7应答；如果第二次发的帧全部正确收到，也是以帧7应答。这样，发送方收到帧7的应答后将无法判断这是表示对所发的8帧丢失或出错的否定应答还是对8帧全部正确到达的肯定应答。但若规定最多发送MaxSeq帧（该例中为7帧），使第一次发送的为0、1、2、3、4、5、6帧，第二次发送的为7、0、1、2、3、4、5帧，即可解决此问题。如果第二次发的帧全部正确收到，应答号为5，若全部出错，则应答号为6.
尽管该协议没有暂存出错以后收到的报文，但同样不能完全避开缓冲的问题。发端有可能重发某些报文，所以它必须提供缓冲空间，直至确知报文已被对方无误收到。当帧n的肯定应答到达发端时，也意味着帧n-1、n-2等也自动地被应答了。这一性质十分重要，尤其是丢失了前面的应答时更为有用。只要收到一个肯定应答，协议程序就可以释放被该肯定应答帧之前所有帧所占用的缓冲器，从而可使主机进入HostReady状态。对于回退n连续ARQ，对缓冲器进行线性管理即可，这可通过采用一个变量加上简单的计算来实现。该协议中采用nbuffered变量计数，使用缓冲器时则用n buffer数组进行循环分配。(www.xing528.com)
因为该协议有多个未应答帧，故对每个未应答帧都要进行计时，一旦超时就要重发。从逻辑上讲，每一个未应答帧各需要一个计时器。但通过软件的方法，仅使用一个硬计时器也可以实现对多个帧的计时。未应答帧的超时计时器用链表的形式构造，每个计时器一个结点，每个结点由帧的顺序号、到超时尚需等待的时间以及指向下一结点的指针构成。每一个计时脉冲将对所有结点的等待时间减1，一旦等待时间减至0，就将引起相应结点的超时事件（TimeOut），同时将该结点从链表中删除。反之，启动一个计时器时，便在链表中插入一个结点，置入所要求的超时时间。
图4.3.8 多个软件计时器的模拟
采用该协议仍假设双方有大量数据，应答全部采用搭载ACK，出错后为超时重发，其程序如下：
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
