关于选择拒绝.pdf

关于选择拒绝ARQ 的疑问 不少同学询问教材164 页图7.9(b)和165 页[TANE96]描述的选择拒绝ARQ 为何不一致。 的确是作者教材编著时统稿的疏漏，[TANE96]描述的情况是经典的，其接收的帧是可以不 按序到来的，只要其序号包含在当前窗口的序号值之内；而164 页图7.9(b)是HDLC 中关于 选择拒绝 ARQ 的实现，其接收的帧只能是按序到来的，该协议对于丢失的确认RR ，发送 方超时则使用询问RR 去询问接收方，而不是直接就重传。两者取材不同，所以有些矛盾。 Stallings 没有对此给出说明，直接抄来拼合在一起，是不当的。 但[TANE96]的描述也有一段内容含混不清，Stallings 对其重新进行了补正，是恰当的。 下面，我将Andrew S. Tanenmaum 在其1996 年出版的《Computer Networks (3e)》[TANE96] 中描述情况翻译如下： 假定有3 比特的序号，因此可以允许发送方连续发送多达7 帧，然后再等待接收一个确 认。初始的发送窗口与接收窗口如图3-19 （a ）所示，发送方发送第0 帧至第6 帧，接收窗 口认可具有0 到6 之间的序号的任意帧。如果7 帧全部正确到达，接收方对其给予确认，并 将窗口向前滑动，准备接收第 7、0、1、2 、3、4 、5 帧，如图3-19 （b ），所有7 个缓冲区 都标记为空。 发送方 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 接收方 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 （a ） （b ） （c ） （d ） 图3-19. （a ）窗口大小为7 的初始状态。（b ）当发送和接收7 帧之后且未确认。 （c ）窗口大小为4 的初态。（d ）当发送和接收7 帧之后且未确认。 译者注：（b ）和（d ）的说法不确切，应该是接收方已确认但发送方尚未收到该确认时 的窗口状态。 就在此时，一个雷电击中了电线杆，把所有的确认都抹掉了。发送方最终超时并重传第 0 帧，当该帧到达接收方后，检验其是否在接收窗口之内。不幸的是，在图3-19 （b ）中， 第0 帧是在新窗口之内，因此将认可该帧。既然第0 帧到第6 帧都已收到，接收方发送一个 对第6 帧的捎带确认。 发送方庆幸地得知它发送的所有帧都被正确地收到，因此它向前滑动自己的窗口，并立 即发送帧第7、0、1、2 、3、4 、5 帧，接收方认可第7 帧，并将（从帧中拆封取出的——译 者加）分组直接传递给网络层。紧接着，接收方的数据链路层检验是否已经有一个有效的第 0 帧，发现果然有，然后将其中嵌入的分组传递给网络层。结果，网络层收到一个不正确的 分组，协议失败。 （上两段中第一段最后一句上下文的衔接上有些问题，Stalling 的描述更容易理解一些 一些。当接收方对前6 帧确认后，实际上接收方希望下面收到的是第7 帧，由于确认帧丢失 引起发送方超时重传，接收方收到却是第0 帧，它会认为重传的第0 帧是新一轮的第0 帧， 该轮的第7 帧（应在第0 帧前发送）传丢了，它会请求重传第7 帧——译者注） 问题的本质是，接收方前移其窗口之后，新的有效序号范围与旧的序号范围重叠，随后 一批帧可能是重复的（如果所有确认都丢失），也可能是新的（如果所有确认都收到）。而接 收方无法区分这两种情况。 跳出这两难境地的方法是，确保接收方前移其窗口后，不与原来的窗口重叠。为保证没 有重叠，最大窗口至多为序号范围的一半，正如图 3-19 （c ）和图 3-19 （d ）所示的那样。 例如，如果4 个比特用于序号，其范围为0 到15，在任何时刻，悬而未决的未确认帧只有8 个。如果接收方已经认可了第0 帧到第7 帧，且前移窗口允许接受第8 帧至第15 帧，它可 以无二义性地告知随后的帧是重传的（0 到 7 ）还是新的（8 到 15）