滑动窗口算法原.docx
《滑动窗口算法原.docx》由会员分享，可在线阅读，更多相关《滑动窗口算法原.docx（9页珍藏版）》请在冰豆网上搜索。
滑动窗口算法原
滑动窗口算法原
————————————————————————————————作者：
————————————————————————————————日期：
1.滑动窗口算法
--------------------------------------------------------------------------------
滑动窗口算法工作过程如下。
首先，发送方为每1帧赋一个序号（sequencenumber），记作SeqNum。
现在，让我们忽略SeqNum是由有限大小的头部字段实现的事实，而假设它能无限增大。
发送方维护3个变量：
发送窗口大小（sendwindowsize），记作SWS，给出发送方能够发
送但未确认的帧数的上界；LAR表示最近收到的确认帧（lastacknowledgementreceived）的序号；LFS表示最近发送的帧（lastframesent）的序号，发送方还维持如下的不变式：
LAR-LFR≤RWS
当一个确认到达时，发送方向右移动LAR，从而允许发送方发送另一帧。
同时，发送方为所发的每个帧设置一个定时器，如果定时器在ACK到达之前超时，则重发此帧。
注意：
发送方必须存储最多SWS个帧，因为在它们得到确认之前必须准备重发。
接收方维护下面3个变量：
接收窗口大小（receivewindowsize），记为RWS，给出接收方所能接收的无序帧数目的上界；LAF表示可接收帧（largestacceptableframe）的序号；LFR表示最近收到的帧（lastframereceived）的序号。
接收方也维持如下不变式：
LFS-LAR≤SWS
当一个具有顺序号SeqNum的帧到达时，接收方采取如下行动：
如果SeqNum≤LFR或SeqNum>LAF，那么帧不在接收窗口内，于是被丢弃；如果LFR＜SeqNum≤LAF，那么帧在接收窗口内，于是被接收。
现在接收方需要决定是否发送一个ACK。
设SeqNumToACK表示未被确认帧的最大序号，则序号小于或等于SeqNumToAck的帧都已收到。
即使已经收到更高序号的分组，接收方仍确认SeqNumToAck的接收。
这种确认被称为是累积的（cumulative）。
然后它设置LFR=SeqNumToAck，并调整LAF=LFR+RWS。
例如，假设LFR=5（即，上次接收方发送的ACK是为了确认顺序号5的），并且RWS=4。
这意味着LAF=9。
如果帧7和8到达，则存储它们，因为它们在接收窗口内。
然而并不需要发送ACK，因为帧6还没有到达。
帧7和8被称为是错序到达的。
（从技术上讲，接收方可以在帧7和8到达时重发帧5的ACK。
）如果帧6当时到达了（或许它在第一次丢失后又重发从而晚到，或许它只是被延迟了），接收方确认帧8，LFR置为8，LAF置为12。
如果实际上帧6丢失了，则出现发送方超时，重发帧6。
我们看到，当发生超时时，传输数据量减少，这是因为发送方在帧6确认之前不能向前移动窗口。
这意味着分组丢失时，此方案将不再保证管道满载。
注意：
分组丢失时间越长，这个问题越严重。
注意，在这个例子中，接收方可以在帧7刚一到达时就为帧6发送一个认帧NAK（negativeacknowledgment）。
然而，由于发送方的超时机制足以发现这种情况，发送NAK反而为发送方增加了复杂性，因此不必这样做。
正如我们已提到的，当帧7和8到达时为帧5发送一个额外的ACK是合理的；在某些情况下，发送方可以使用重复的ACK作为一个帧丢失的线索。
这两种方法都允许早期的分组丢失检测，有助于改进性能。
关于这个方案的另一个变种是使用选择确认（selectiveacknowledgements）。
即，接收方能够准确地确认那些已收到的帧，而不只是确认按顺序收到最高序号的帧。
因此，在上例中，接收方能够确认帧7、8的接收。
如果给发送方更多的信息，就能使其较容易地保持管道满载，但增加了实现的复杂性。
发送窗口大小是根据一段给定时间内链路上有多少待确认的帧来选择的；对于一个给定的延迟与带宽的乘积，SWS是容易计算的。
另一方面，接收方可以将RWS设置为任何想要的值。
通常的两种设置是：
RWS=1，表示接收方不存储任何错序到达的帧；RWS=SWS，表示接收方能够缓存发送方传输的任何帧。
由于错序到达的帧的数目不可能超过SWS个，所以设置RWS>SWS没有意义。
2.有限顺序号和滑动窗口
--------------------------------------------------------------------------------
现在我们再来讨论算法中做过的一个简化，即假设序号是可以无限增大的。
当然，实际上是在一个有限的头部字段中说明一个帧的序号。
例如，一个3比特字段意味着有8个可用序号0~7。
因此序号必须可重用，或者说序号能回绕。
这就带来了一个问题：
要能够区别同一序号的不同次发送实例，这意味着可用序号的数目必须大于所允许的待确认帧的数目。
例如，停止等待算法允许一次有1个待确认帧，并有2个不同的序号。
假设序号空间中的序号数比待确认的帧数大1，即SWS≤MAaxSeqNum-1，其中MaxSeqNum是可用序号数。
这就够了吗？
答案取决于RWS。
如果RWS=1，那么MaxSeqNum≥SWS+1是足够了。
如果RWS等于SWS，那么有一个只比发送窗口尺寸大1的MaxSeqNum是不够的。
为看清这一点，考虑有8个序号0~7的情况，并且SWS=RWS=7。
假设发送方传输帧0~6，并且接收方成功接收，但ACK丢失。
接收方现在希望接收帧7，0~5，但发送方超时，然后发送帧0~6。
不幸的是，接收方期待的是第二次的帧0~5，得到的却是第一次的帧0~5。
这正是我们想避免的情况。
结果是，当RWS=SWS时，发送窗口的大小不能大于可用序号数的一半，或更准确地说，SWS<（Maxseqnum+1）/2直观地，这说明滑动窗口协议是在序号空间的两半之间变换，就像停止等待协议的序号是在0和1之间变换一样。
唯一的区别是，它在序号空间的两半之间连续滑动而不是离散的变换。
注意，这条规则是特别针对RWS=SWS的。
我们把确定适用于RWS和SWS的任意值的更一般的规则留做一个练习。
还要注意，窗口的大小和序号空间之间的关系依赖于一个很明显以至于容易被忽略的假设，即帧在传输中不重新排序。
这在直连的点到点链路上不能发生，因为在传输过程中一个帧不可能赶上另一个帧。
然而，我们将在第5章看到用在一个不同环境中的滑动窗口算法，并且需要设计另一条规则。
3.滑动窗口的实现
--------------------------------------------------------------------------------
下面的例程说明我们如何实现滑动窗口算法的发送和接收的两个方面。
该例程取自一个正在使用的协议，称为滑动窗口协议SWP（SlidingWindowProtocol）。
为了不涉及协议图中的邻近协议，我们用HLP（高层协议）表示SWP上层的协议，用LINK（链路层协议）表示SWP下层的协议。
我们先定义一对数据结构。
首先，帧头部非常简单：
它包含一个序号（SeqNum）和一个确认号（AckNum）。
它还包含一个标志（Flags）字段，表明帧是一个ACK帧还是携带数据的帧。
其次，滑动窗口算法的状态有如下结构。
对于协议发送方，该状态包括如上所述的变量LAR和LFS，以及一个存放已发出但尚未确认的帧的队列（sendQ）。
发送方状态还包含一个计数信号量（countingsemaphore），称为sendWindowNotFull。
下面我们将会看到如何使用它，但一般来说，信号量是一个支持semWait和semSignal操作的同步原语。
每次调用SemSignal，信号量加1，每次调用SemWait，信号量减1。
如果信号量减小，导致它的值小于0，那么调用进程阻塞（挂起）。
一旦执行了足够的semSignal操作而使信号量的值增大到大于0，在调用semWait的过程中阻塞的进程就允许被恢复。
对于协议的接收方，如前所述，该状态包含变量LFR，加上一个存放已收到的错序帧的队列（recvQ）。
最后，虽然未显示，发送方和接收方的滑动窗口的大小分别由常量SWS和RWS表示。
SWP的发送方是由sendSWP过程实现的。
这个例程很简单。
首先，semWait使这个进程在一个信号量上阻塞，直到它可以发另一帧。
一旦允许继续，sendSWP设置帧头部中的顺序号，将此帧的拷贝存储在发送队列（sendQ）中，调度一个超时事件以便处理帧未被确认的情况，并将帧发给低层协议。
值得注意的一个细节是刚好在调用msgAddHdr之前调用store_swp_hdr。
该例程将存有SWP头部的C语言结构（state->hdr）转化为能够安全放在消息前面的字节串（hbuf）。
该例程（未给出）必须将头部中的每一个整数字段转化为网络字节顺序，并且去掉编译程序加入C语言结构中的任意填充。
7.1节将详细讨论字节顺序的问题，但现在，假设该例程将多字整数中最高有效位放在最高地址字节就足够了。
这个例程的另一个复杂性是使用semWait和sendWindowNotFull信号量。
SendWindowNotFull被初始化为发送方滑动窗口的大小SWS（未给出这一初始化）。
发送方每传输一帧，semWait操作将这个数减1，如果减小到0，则阻塞发送方进程。
每收到一个ACK，在deliverSWP中调用semSignal操作（见下面）将此数加1，从而激活正在等待的发送方进程。
在继续介绍SWP的接收方之前，需要调整一个看上去不一致的地方。
一方面，我们说过，高层协议通过调用send操作来请求低层协议的服务，所以我们就希望通过SWP发送消息的协议能够调用send（SWP,packet）。
另一方面，用来实现SWP的发送操作的过程叫做sendSWP，并且它的第一个参数是一个状态变量（SwpState）。
结果怎样呢？
答案是，操作系统提供了粘结代码将对send的一般调用转化为对sendSWP的特定协议调用的粘结代码。
这个粘结代码将send的第一个参数（协议变量SWP）映射为一个指向sendSWP的函数指针和一个指向SWP工作时所需的协议状态的指针。
我们之所以通过一般函数调用使高层协议间接调用特定协议函数，是因为我们想限制高层协议中对低层协议编码的信息量。
这使得将来能够比较容易地改变协议图的配置。
现在来看deliver操作的SWP的特定协议实现，它在过程deliverSWP中实现。
这个例程实际上处理两种不同类型的输入消息：
本结点已发出帧的ACK和到达这个结点的数据帧。
在某种意义上，这个例程的ACK部分是与sendSWP中所给算法的发送方相对应的。
通过检验头部的Flags字段可以确定输入的消息是ACK还是一个数据帧。
注意，这种特殊的实现不支持数据帧中捎带ACK。
当输入帧是一个ACK时，deliverSWP仅仅在发送队列（sendQ）中找到与此ACK相应的位置（slot），取消超时事件，并且释放保存在那一位置的帧。
由于ACK可能是累积的，所以这项工作实际上是在一个循环中进行的。
对于这种情况值得注意的另一个问题是子例程swpInWindow的调用。
这个子例程在下面给出，它确保被确认帧的序号是在发送方当前希望收到的ACK的范围之内。
当输入帧包含数据时，deliverSWP首先调用msgStripHdr和load_swp_hdr以便从帧中提取头部。
例程load_swp_hdr对应着前面讨论的store_swp_hdr，它将一个字节串转化为容纳SWP头部的C语言数据结构。
然后deliverSWP调用swpInWindow以确保帧序号在期望的序号范围内。
如果是这样，例程在已收到的连续的帧的集合上循环，并通过调用deliverHLP例程将它们传给上层协议。
它也要向发送方发送累积的ACK，但却是通过在接收队列上循环来实现的（它没有使用本节前面给出的seqNumToAck变量）。
最后，swpInWindow是一个简单的子例程，它检查一个给定的序号是否落在某个最大和最小顺序号之间。
4.帧顺序和流量控制
--------------------------------------------------------------------------------
滑动窗口协议可能是计算机网络中最著名的算法。
然而，关于该算法易产生混淆的是，它可以有三个不同的功能，第一个功能是本节的重点，即在不可靠链路上可靠地传输帧。
（一般来说，该算法被用于在一个不可靠的网络上可靠地传输消息。
）这是该算法的核心功能。
滑动窗口算法的第二个功能是用于保持帧的传输顺序。
这在接收方比较容易实现，因为每个帧有一个序号，接收方要保证已经向上层协议传递了所有序号比当前帧小的帧，才向上传送该当前帧。
即，接收方缓存了（即没有传送）错序的帧。
本节描述的滑动窗口算法确实保持了帧的顺序，尽管我们可以想象一个变异，即接收方没有等待更早传送的帧都到达就将帧传给下一个协议。
我们可以提出的一个问题是：
我们是否确实需要滑动窗口协议来保持帧的顺序，或者，这样的功能在链路层是否是不必要的。
不幸的是，我们还没有看到足够多的网络体系结构来回答这个问题我们首先需要理解的是，点到点链路序列如何由交换机连接而形成一条端到端的路径。
滑动窗口算法的第三个功能是，它有时支持流量控制（flowcontrol），它是一种接收方能够控制发送方使其降低速度的反馈机制。
这种机制用于抑制发送方发送速度过快，即抑制传输比接收方所能处理的更多的数据。
这通常通过扩展滑动窗口协议完成，使接收方不仅确认收到的帧，而且通知发送方它还可接收多少帧。
可接收的帧数对应着接收方空闲的缓冲区数。
在按序传递的情况下，在将流量控制并入滑动窗口协议之前，我们应该确信流量控制在链路层是必要的。
尚未讨论的一个重要概念是系统设计原理，我们称其为相关性分离（separationofconcerns）。
即，你必须小心区别有时交织在一种机制中的不同功能，并且你必须确定每一个功能是必要的，而且是被最有效的方式支持的。
在这种特定的情况下，可靠传输、按序传输和流量控制有时组合在一个滑动窗口协议里，我们应该问问自己，在链路层这样做是否正确。
带着这样的疑问，我们将在第3章（说明X.25网如何用它实现跳到跳的流量控制）和第5章（描述TCP如何用它实现可靠的字节流信道）重新考虑滑动窗口算法。
升级会员 