滑动窗口协议 .
仍然考虑链路的延迟与带宽的乘积为8 K B,帧尺寸为1 K B的情形。让发送方在收到第一帧的A C K的同时准备发送第九帧。允许我们这样做的算法称为滑动窗口( sliding window),时间线如图2 - 2 1所示。
1. 滑动窗口算法
滑动窗口算法工作过程如下。首先,发送方为每1帧赋一个序号(sequence number),记作S e q N u m。现在,让我们忽略S e q N u m是由有限大小的头部字段实现的事实,而假设它能无限增大。发送方维护3个变量:发送窗口大小(send window size),记作S W S,给出发送方能够发
注意,在这个例子中,接收方可以在帧7刚一到达时就为帧6发送一个认帧N A K(negative acknowl edgment)。然而,由于发送方的超时机制足以发现这种情况,发送N A K反而为发送方增加了复杂性,因此不必这样做。正如我们已提到的,当帧7和8到达时为帧5发送一个额外的A C K是合理的;在某些情况下,发送方可以使用重复的A C K作为一个帧丢失的线索。这两种方法都允许早期的分组丢失检测,有助于改进性能。
关于这个方案的另一个变种是使用选择确认(selective acknowledgements)。即,接收方能够准确地确认那些已收到的帧,而不只是确认按顺序收到最高序号的帧。因此,在上例中,接收方能够确认帧7、8的接收。如果给发送方更多的信息,就能使其较容易地保持管道满载,但增加了实现的复杂性。
2. 有限顺序号和滑动窗口
现在我们再来讨论算法中做过的一个简化,即假设序号是可以无限增大的。当然,实际上是在一个有限的头部字段中说明一个帧的序号。例如,一个3比特字段意味着有8个可用序号0 ~ 7。因此序号必须可重用,或者说序号能回绕。这就带来了一个问题:要能够区别同一序号的不同次发送实例,这意味着可用序号的数目必须大于所允许的待确认帧的数目。例如,停止等待算法允许一次有1个待确认帧,并有2个不同的序号。
假设序号空间中的序号数比待确认的帧数大1,即S W S ≤ M A a x S e q N u m -1 ,其中M a x Seq N u m 是可用序号数。这就够了吗?答案取决于RW S 。如果RW S = 1,那么MaxSeqNum≥SWS+1是足够了。如果RW S等于S W S,那么有一个只比发送窗口尺寸大1的M a x S e q N u m是不够的。为看清这一点,考虑有8个序号0 ~ 7的情况,并且S W S = RW S = 7。假设发送方传输帧0 ~ 6,并且接收方成功接收,但A C K丢失。接收方现在希望接收帧7,0 ~ 5,但发送方超时,然后发送帧0 ~ 6。不幸的是,接收方期待的是第二次的帧0 ~ 5,得到的却是第一次的帧0 ~ 5。这正是我们想避免的情况。
结果是,当RW S = S W S时,发送窗口的大小不能大于可用序号数的一半,或更准确地说,SWS<(Maxseqnum+1)/2直观地,这说明滑动窗口协议是在序号空间的两半之间变换,就像停止等待协议的序号是在0和1之间变换一样。唯一的区别是,它在序号空间的两半之间连续滑动而不是离散的变换。
注意,这条规则是特别针对RW S = S W S的。我们把确定适用于RW S和S W S的任意值的更一般的规则留做一个练习。还要注意,窗口的大小和序号空间之间的关系依赖于一个很明显以至于容易被忽略的假设,即帧在传输中不重新排序。这在直连的点到点链路上不能发生,因为在传输过程中一个帧不可能赶上另一个帧。然而,我们将在第5章看到用在一个不同环境中的滑动窗口算法,并且需要设计另一条规则。
下面的例程说明我们如何实现滑动窗口算法的发送和接收的两个方面。该例程取自一个正在使用的协议,称为滑动窗口协议S W P(Sliding Window Pro t o c o l)。为了不涉及协议图中的邻近协议,我们用H L P(高层协议)表示S W P上层的协议,用L I N K(链路层协议)表示S W P下层的协议。我们先定义一对数据结构。首先,帧头部非常简单:它包含一个序号( S e q N u m)和一个确认号( A c k N u m)。它还包含一个标志( F l a g s)字段,表明帧是一个A C K帧还是携带数据的帧。
对于协议的接收方,如前所述,该状态包含变量L F R ,加上一个存放已收到的错序帧的队列(r e c v Q)。最后,虽然未显示,发送方和接收方的滑动窗口的大小分别由常量S W S和RW S表示。
这个例程的另一个复杂性是使用s e m Wa i t 和s e n dW i n d o w N o t F u l l 信号量。S e n dWi n d o w N o t F u l l被初始化为发送方滑动窗口的大小S W S(未给出这一初始化)。发送方每传输一帧, s e m Wa i t操作将这个数减1,如果减小到0,则阻塞发送方进程。每收到一个A C K,在d e l i v e r S W P中调用s e m S i g n a l操作(见下面)将此数加1,从而激活正在等待的发送方进程。
在继续介绍S W P的接收方之前,需要调整一个看上去不一致的地方。一方面,我们说过,高层协议通过调用s e n d操作来请求低层协议的服务,所以我们就希望通过S W P发送消息的协议能够调用s e n d(S W P, p a c k e t)。另一方面,用来实现S W P的发送操作的过程叫做s e n d S W P,并且它的第一个参数是一个状态变量( S w p S t a t e)。结果怎样呢?答案是,操作系统提供了粘结代码将对s e n d的一般调用转化为对s e n d S W P的特定协议调用的粘结代码。这个粘结代码将s e n d的第一个参数(协议变量S W P)映射为一个指向s e n d S W P的函数指针和一个指向S W P工作时所需的协议状态的指针。我们之所以通过一般函数调用使高层协议间接调用特定协议函数,是因为我们想限制高层协议中对低层协议编码的信息量。这使得将来能够比较容易地改变协议图的配置。现在来看d e l i v e r操作的S W P的特定协议实现,它在过程d e l i v e r S W P中实现。这个例程实际上处理两种不同类型的输入消息:本结点已发出帧的A C K和到达这个结点的数据帧。在某种意义上,这个例程的ACK部分是与send SWP中所给算法的发送方相对应的。通过检验头部的F l a g s字段可以确定输入的消息是ACK还是一个数据帧。注意,这种特殊的实现不支持数据帧中捎带A C K。当输入帧是一个ACK时,delive rSWP仅仅在发送队列(send Q)中找到与此ACK相应的位置(slot),取消超时事件,并且释放保存在那一位置的帧。由于A C K可能是累积的,所以这项工作实际上是在一个循环中进行的。对于这种情况值得注意的另一个问题是子例程swp In Wind o w的调用。这个子例程在下面给出,它确保被确认帧的序号是在发送方当前希望收到的A C K的范围之内。
当输入帧包含数据时, d e l i v e r S W P首先调用m s g S t r i p H d r和l o a d _ s w p _ h d r以便从帧中提取头部。例程l o a d _ s w p _ h d r对应着前面讨论的s t o r e _ s w p _ h d r,它将一个字节串转化为容纳S W P头部的C语言数据结构。然后d e l i v e r S W P调用s w p I n Wi n d o w以确保帧序号在期望的序号范围内。如果是这样,例程在已收到的连续的帧的集合上循环,并通过调用d e l i v e r H L P例程将它们传给上层协议。它也要向发送方发送累积的A C K,但却是通过在接收队列上循环来实现的(它没有使用本节前面给出的s e q N u m To A c k变量)。
滑动窗口算法的第三个功能是,它有时支持流量控制(f l o w c o n t ro l),它是一种接收方能够控制发送方使其降低速度的反馈机制。这种机制用于抑制发送方发送速度过快,即抑制传输比接收方所能处理的更多的数据。这通常通过扩展滑动窗口协议完成,使接收方不仅确认收到的帧,而且通知发送方它还可接收多少帧。可接收的帧数对应着接收方空闲的缓冲区数。在按序传递的情况下,在将流量控制并入滑动窗口协议之前,我们应该确信流量控制在链路层是必要的。
尚未讨论的一个重要概念是系统设计原理,我们称其为相关性分离(separation of concerns)。即,你必须小心区别有时交织在一种机制中的不同功能,并且你必须确定每一个功能是必要的,而且是被最有效的方式支持的。在这种特定的情况下,可靠传输、按序传输和流量控制有时组合在一个滑动窗口协议里,我们应该问问自己,在链路层这样做是否正确。带着这样的疑问,我们将在第3章(说明X. 2 5网如何用它实现跳到跳的流量控制)和第5章(描述T C P如何用它实现可靠的字节流信道)重新考虑滑动窗口算法。