滑动窗口协议实验报告

滑动窗口协议实验报告

篇一：实验二滑动窗口协议实验报告2

＜滑动窗口协议的模拟＞

项目设计报告

作者：完成日期：

签收人：签收日期：

1 需求分析

实验目的：加深对滑动窗口协议的理解

实验任务：实现对于滑动窗口协议的模拟

实验环境：PC机

操作系统：Windows XP

开发环境：Microsoft Visual C++ ，可以使用MFC类库

问题重述

界面要求：

项目要求的所有功能应可视，要有

简单的界面。

由一台PC（或线程）向另一台PC （或线程）发送数据包时，界面应显示出双方帧个数的变化，帧序号，发送和接受速度，暂停或重传提示等，界面中必须动态显示数据帧的发送和接受情况，包括在相应的窗口详细显示相应的ACK和其他收发数据帧后发出的消息，以表明模拟协议的正确运作过程。

在各种情况下，接受方和发送方窗口应实时显示帧的发送和接受情况，包括序号，时间戳，内容等。以及窗口的填充和清空情况。

网络接口要求：

两台机器或是一台机器中两个独立的线程模拟发送方与接受方，接收数据的端口初始应为监听状态。

发送方向接受方发起连接，成功后开始发送数据。

接受方要求：

接受方应由固定大小的滑动窗口，并对收到信息缓存。当发送方速度过快

或帧丢失（超时），接受方应发送消息，要求暂停或是重传（停---等协议）。

接受方要求按序向网络层提交收到的帧。

发送方要求：

发送方发送速度可以调节，并可以暂停或是重发。

发送方重传时可仅重传需要的帧。

可指定滑动窗口数目和要发送的帧的总数，停等的超时时间间隔以及发送类型（正常发送，错序发送，以

及缺帧，丢帧的现象），发送速率等参数。

2 概要设计

原理概述

发送方和接受方都维持了一个窗口，窗口内部包含了那些可以接受的序列号。

发送方的窗口大小从0开始，以后可以增大到某一个预设的最大值。由于发送方可能在将来的某个时刻重传未被确认的帧，所以它必须把已经送出去的

帧保留一段时间，直到他知道接受方已经接受了这些帧。当第n帧的确认到来时，第n-1,第n-2等也都被自动地确认了。

接受方的窗口总是固定大小的。接受方为其窗口内的每一个序列号保留了一个缓冲区。与每个缓冲区相连关联的还有一位，用来指明该缓冲区是满的还是空的。任何时候当一帧到达时，

接受方通过between函数检查它的序列号，看是否落在窗口内。如果确实落在窗口内，并且以前还没有收到这一帧，则接受该帧，并且保存起来。而不管这一帧是否包含网络层所期望的下一个分组，这个过程是肯定要执行的。该帧被保存在数据链路层中，直到所有序列号比他小的那些帧都已经按照正确的顺序提交给网络层之后，他才会被传递给网络层。

主要问题

问题一：如何模拟网络层的数据流量？

因为是模拟滑动窗口协议，为了使

项目能够进行下去，先做两个假设：假设一：发送方的网络层总有数据需要发送

假设二：接受方没有反向流量，因此不能捎带确认，每次等待辅助定时器超时之后发送一个不带数据

的ACK.

为了解决这个问题，我在发送方设置了一个发送定时器，定时间隔与发送速率一致。发送定时器每触发一次，一个数据包（新的数据包或者重发数据包）被送出。这样就可以通过调节该定时器调节发送方的发送速度。

问题二：如何模拟接受方的接收速率？

考虑到发送方发送数据包是在定时器的控制下主动地发送比较好控制，而用套接字编程时，数据包一到自然接收，如果不采取特殊的措施是无法控制接受速率的。因此在接受方设置一个接受定时器，时间间隔与接受速率一致。类似网络层中为了控制突发流量所采用的令

牌桶算法，接受定时器每触发一次，接受方就获得一块令牌，在有令牌的情况下，发送方的数据包到来才可以接受，否则就不作处理，当作丢失了。而且在已经有令牌的情况下，接受定时器再被触发，也不增加令牌的数量，始终只有一块。这样就大致控制了接收速率。

问题三：如何模拟信道出现的状况？

考虑到在实际的传输过程中信道可能出现丢包，或是干扰信号导致出错，但是在传输层上做实验的时候，这些错误已经被下层处理过了，我能看到的是一个可靠的数据位流。因此只好人工模拟出错和丢包的情况。具体是这样实现的，在数据包内增加一个校验和域，当然校验和本来不应该放在数据包内（在写程序的时候，没有明确区分网络层的数据包和数据链路层的帧的概念，无伤大雅但是显的概念不清，以后注意改进）。这里的校验和其实只是指明该帧是否在信道中被丢弃或是出错。接受方将

通过检查这一位对不同的数据包进行不同的处理（或者不处理）。

问题四：如何理解错序发送？

在具体实现中，按照错序发送模式下输入的顺序逐个发送数据包，并逐个启动重发定时器，没有被发送的数据包就当作是在传输过程中遗失了。

问题五：关于序列号的范围，发送窗口大小，接收窗口大小，缓冲区大小以及重发定时器数量的关系。

接受方窗口的尺寸应该不超过序列号范围的一半，以确保接收方向向前移动窗口之后，新的窗口与老的窗口之间没有重叠。接受方所需的缓冲区和定时器数量等于窗口的尺寸而不是序列号的范围。

问题六：关于nak的理解

当接受方有理由怀疑出现了错误时，他就给发送方送回一个否定的确认（nak）帧。这样的帧实际上是一个重传请求，在nak中指定了要重传的帧。有两种情况接受方应该怀疑：接受到一个

受损的帧，或者到达的帧并非是自己所期望的。为了避免多次请求重传同一个丢失的帧，接受方应该记录下对于某一帧是否已经发送过nak。如果对于frame_expected

还没有发送过nak，则变量no_nak 为true.如果nak被损坏了，或者丢失了，则不会有实质性的伤害，因为发送方最终会超时，无论如何会重传丢失的帧。如果一个nak被发送出去之后丢了，而接受方又收到一个错误的帧，则no_nak 将为true,并且辅助定时器将被启动。当辅助定时器超时后，一个ack帧将被发送出去，以便将发送方重新同步到接受方的当前状态。

数据结构

数据包的结构：

Cstring framekind

数据包的类型，可能是数据（），确认（），否定性确认（），其实对于接受方来说这个域是没有意义的，因为他收到的总是数据，但是对发送方来说，就

需要区分确认信息与否定确认。本来数据包和消息可以用不同的数据结构，但是考虑到程序的可扩展性（例如，一个线程内同时收发数据，或是有捎带确认等等），所以采用一样的结构。

Cstring seq

对于数据类型的包来说，这个域指明了数据包的序列号。对于确认信息来说，这个域说明了到这个序列号之前的所有数据包都已经收到。对于否定性确认来说，这个域放的是需要重传的数据包的序列号。

Cstring info

数据包的内容，没有什么意义。

Cstring tm

时间戳，指明了该数据包被生成（或发送）的时间，通过这个域的信息，可以区分重传的帧。

Cstring cksum

校验和，详见前面的说明。当这个域为0时，说明这个数据包没有受损，也没有被丢失。这个域为1表示数据包

受损，大于2表示数据包被丢弃，程序接收到数据包之后首先查看这个域的值，然后交付相应的分支进行处理。

发送窗口的数据结构：

int ack_expected

发送窗口的下界，表示最小的尚未被确认的帧，收到接受方的ack之后，向前滑动这个值。int frame_to_send 发送窗口的上界，指出了当前待发送的帧序号，每成功发送一帧，向前滑动一位，直到窗口满为止。

int nbuffer

指出了当前发送窗口的大小,即尚未被确认的帧的个数.通过对这个值的检验,可以强行关闭或打开网络层,以避免网络层流量太大导致缓冲区溢出.

接收窗口的数据结构:

int frame_expected

接收窗口的下界,即当前期望接收到的帧.当链路层将数据包顺序提交网络层之后,接收窗口整个向前滑动.

int too_far

接收窗口的上界,序列号落在这两个值之间的数据包,接受方都为之准备了缓存空间.而序列号掉在窗口外的那些数据包则认为是已经过期的数据包,直接扔掉.

booleanarrived[ ]

因为是选择性重传的协议,在收到一个错误的数据包之后不会将之后的数据包统统丢弃,而是缓存起来,所以需要指明接受缓冲区内那些数据包已经收到,那些还没有收到.

算法分析

以下用伪代码的形式分别给出接收方和发送方的基本算法

sender:

void protocol

{

int ack_expected;

int next_frame_to_send;

int nbuffer;

packet out_buf[NR_BUFS];

int i;

frame r;

enable_network_layer;

ack_expected=0;

next_frame_to_send=0;

nbuffer=0;

while

{

wait_for_event

switch

{

case network_layer_ready: nbuffer=nbuffer+1;

get a packet from network layer; send that packet and start timer; inc;

break;

case frame_arrival:

get a framet from physical layer; if

prepare to send that packet again; if

{

while)

{

nbuffer=nbuffer-1;

stop_timer;

inc;

篇二：实验一滑动窗口协议实验

实验一滑动窗口协议实验

? 实验目的：

在NetRiver实验系统中，用C语言实现滑动窗口协议中的1比特滑动窗口协议和后退N帧协议，理解滑动窗口协议

? 实验原理和说明：

（1）.窗口机制

滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方

窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设发送窗口尺寸为2，接收窗口尺寸为1）：

分析：①初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；②发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；

③发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；④接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；⑤发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；⑥发送方继续发送2号帧，2号窗口打开，表示

2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；⑦接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；⑧发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。

若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退n协议：发窗口>1，接收窗口>1；选择重传协议：发送窗口>1,接收窗口>1。

（2）.1比特滑动窗口协议

当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方

已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。

.后退n协议

由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信

息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。

从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。

.选择重传协议

在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。

一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发，其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。

? 实验代码以及代码说明：

实现代码如下：

#include ““

#include

using std :: deque;

using std :: cout;

using std :: endl;

using namespace std;

extern void SendFRAMEPacket;

#define WINDOW_SIZE_STOP_WAIT 1

#define WINDOW_SIZE_BACK_N_FRAME 4 /* the max windows size */

typedef enum {data, ack, nak} frame_kind;

/* define the structure of frame and frame head */

typedef struct frame_head {

frame_kind kind;

unsigned int seq;

unsigned int ack;

unsigned char data[100];

};

typedef struct frame {

frame_head head;

unsigned int size;

};

/* define the buffer zone */

struct StoreType {

frame *pfrm;

unsigned int sz;

};

deque mQue;

deque mQue2;

bool sendWinFull = false;

int counter = 0;

/*

* 停等协议测试函数

*/

int stud_slide_window_stop_and_wait {

unsigned int ack;

unsigned int num;

StoreType s;

/* by the messagetype to decide */

switch {

case MSG_TYPE_TIMEOUT:

num = ntohlpBuffer);

s = ;

/* if the seq is OK,send it */

if .)) {

SendFRAMEPacket, );

}

break;

case MSG_TYPE_SEND:

/* prepare a new frame */

= new frame;

= *pBuffer;

= bufferSize;