滑动窗口协议实验报告.docx
《滑动窗口协议实验报告.docx》由会员分享，可在线阅读，更多相关《滑动窗口协议实验报告.docx（19页珍藏版）》请在冰豆网上搜索。
滑动窗口协议实验报告
滑动窗口协议实验报告
篇一：
实验二滑动窗口协议实验报告2
＜滑动窗口协议的模拟＞
项目设计报告
作者：
完成日期：
签收人：
签收日期：
1需求分析
实验目的：
加深对滑动窗口协议的理解
实验任务：
实现对于滑动窗口协议的模拟
实验环境：
PC机
操作系统：
WindowsXP
开发环境：
MicrosoftVisualC++，可以使用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帧将被发送出去，以便将发送方重新同步到接受方的当前状态。
数据结构
数据包的结构：
Cstringframekind
数据包的类型，可能是数据（），确认（），否定性确认（），其实对于接受方来说这个域是没有意义的，因为他收到的总是数据，但是对发送方来说，就需要区分确认信息与否定确认。
本来数据包和消息可以用不同的数据结构，但是考虑到程序的可扩展性（例如，一个线程内同时收发数据，或是有捎带确认等等），所以采用一样的结构。
Cstringseq
对于数据类型的包来说，这个域指明了数据包的序列号。
对于确认信息来说，这个域说明了到这个序列号之前的所有数据包都已经收到。
对于否定性确认来说，这个域放的是需要重传的数据包的序列号。
Cstringinfo
数据包的内容，没有什么意义。
Cstringtm
时间戳，指明了该数据包被生成（或发送）的时间，通过这个域的信息，可以区分重传的帧。
Cstringcksum
校验和，详见前面的说明。
当这个域为0时，说明这个数据包没有受损，也没有被丢失。
这个域为1表示数据包受损，大于2表示数据包被丢弃，程序接收到数据包之后首先查看这个域的值，然后交付相应的分支进行处理。
发送窗口的数据结构：
intack_expected
发送窗口的下界，表示最小的尚未被确认的帧，收到接受方的ack之后，向前滑动这个值。
intframe_to_send
发送窗口的上界，指出了当前待发送的帧序号，每成功发送一帧，向前滑动一位，直到窗口满为止。
intnbuffer
指出了当前发送窗口的大小,即尚未被确认的帧的个数.通过对这个值的检验,可以强行关闭或打开网络层,以避免网络层流量太大导致缓冲区溢出.
接收窗口的数据结构:
intframe_expected
接收窗口的下界,即当前期望接收到的帧.当链路层将数据包顺序提交网络层之后,接收窗口整个向前滑动.
inttoo_far
接收窗口的上界,序列号落在这两个值之间的数据包,接受方都为之准备了缓存空间.而序列号掉在窗口外的那些数据包则认为是已经过期的数据包,直接扔掉.
booleanarrived[]
因为是选择性重传的协议,在收到一个错误的数据包之后不会将之后的数据包统统丢弃,而是缓存起来,所以需要指明接受缓冲区内那些数据包已经收到,那些还没有收到.
算法分析
以下用伪代码的形式分别给出接收方和发送方的基本算法
sender:
voidprotocol
{
intack_expected;
intnext_frame_to_send;
intnbuffer;
packetout_buf[NR_BUFS];
inti;
framer;
enable_network_layer;
ack_expected=0;
next_frame_to_send=0;
nbuffer=0;
while
{
wait_for_event
switch
{
casenetwork_layer_ready:
nbuffer=nbuffer+1;
getapacketfromnetworklayer;
sendthatpacketandstarttimer;
inc;
break;
caseframe_arrival:
getaframetfromphysicallayer;
if
preparetosendthatpacketagain;
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
usingstd:
:
deque;
usingstd:
:
cout;
usingstd:
:
endl;
usingnamespacestd;
externvoidSendFRAMEPacket;
#defineWINDOW_SIZE_STOP_WAIT1
#defineWINDOW_SIZE_BACK_N_FRAME4/*themaxwindowssize*/
typedefenum{data,ack,nak}frame_kind;
/*definethestructureofframeandframehead*/
typedefstructframe_head{
frame_kindkind;
unsignedintseq;
unsignedintack;
unsignedchardata[100];
};
typedefstructframe{
frame_headhead;
unsignedintsize;
};
/*definethebufferzone*/
structStoreType{
frame*pfrm;
unsignedintsz;
};
dequemQue;
dequemQue2;
boolsendWinFull=false;
intcounter=0;
/*
*停等协议测试函数
*/
intstud_slide_window_stop_and_wait{
unsignedintack;
unsignedintnum;
StoreTypes;
/*bythemessagetypetodecide*/
switch{
caseMSG_TYPE_TIMEOUT:
num=ntohlpBuffer）;
s=;
/*iftheseqisOK,sendit*/
if.））{
SendFRAMEPacket,）;
}
break;
caseMSG_TYPE_SEND:
/*prepareanewframe*/
=newframe;
=*pBuffer;
=bufferSize;
_back;
/*sendallthedatainbuffer*/
if{
s=;
SendFRAMEPacket,）;
sendWinFull=true;
}
break;
caseMSG_TYPE_RECEIVE:
/*receiveack*/
ack=ntohlpBuffer）->）;
if!
=0）{
s=;
if==ack）/*receiverightackseqnumber*/{
_front;
s=;
SendFRAMEPacket）,）;/*sendframesagain*/}
}
else
{
sendWinFull=true;/*databufferisempty*/
}
break;
}
return0;
}
/*
*回退n帧测试函数
*/
intstud_slide_window_back_n_frame{
intack;
intnum;
篇三：
滑动窗口协议实验报告
数据链路层滑动窗口协议实验报告
1实验任务
对实际系统中的协议分层和协议软件的设计与实现有基本的认识。
2实验内容
利用所学数据链路层原理，自己设计一个滑动窗口协议并在仿真环境下编程实现有噪音信道环境下的可靠的双工通信。
信道模型为8000bps全双工卫星信道，信道传播时延270毫秒，信道误码率为10-5，信道提供字节流传输服务，网络层分组长度在240~256字节范围。
通过该实验，进一步巩固和深刻理解数据链路层的字节填充方式的成帧技术，误码检测的CRC校验技术，以及滑动窗口的工作机理。
滑动窗口机制的两个主要目标：
实现有噪音信道环境下的无差错传输;充分利用传输信道的带宽。
在程序能够稳定运行并成功实现第一个目标之后，运行程序并检查在信道没有误码和存在误码两种情况下的信道利用率。
为实现第二个目标，提高滑动窗口协议信道利用率，需要根据信道实际情况合理地为协议配置工作参数，包括滑动窗口的大小和重传定时器时限以及ACK搭载定时器的时限。
这些参数的设计，需要充分理解滑动窗口协议的工作原理并利用所学的理论知识，经过认真的推算，计算出最优取值，并通过程序的运行进行验证。
对实际系统中的协议分层和协议软件的设计与实现有基本的认识。
利用仿真环境下所提供的物理层服务和定时器机制为网络层提供服务。
程序的总体结构
设数据链路层通信的两个站点分别为站点A和站点B，仿真环境利用WindowsXP环境下的TCP协议和Socket客户端/服务器机制构建两个站点之间的通信，其中，站点A为服务器端，站点B为客户端。
编译、链接之后最终生成的可执行程序为字符界面命令行程序（不是图形界面程序）。
可执行程序文件仅有一份，设为，在WindowsXP的两个DOS窗口中使用不同的命令行参数启动两个进程，分别仿真站点A和站点B。
实验环境所提供的文件和编译运行方法
实验环境使用VisualC++系统
，：
Microsoft的工程文件，包括Win32Debug和Win32Release两种配置。
：
库函数中包括的函数原型以及相关的宏定义，调用库函数的C语言源程序应当#include此文件。
：
应当由同学完成的数据链路层程序文件。
许多同学C语言源程序书写格式凌乱，请参阅“附录一源程序书写格式要求”。
Debug/：
Win32Debug配置所需要的库文件。
Release/：
Win32Release配置所需要的库文件。
：
使用搭载ACK技术的Go-Back-N协议的一种参考实现，可以直接运行以了解本次实验应达到的目的。
：
使用选择重传协议的一种参考实现。
4协议设计
按照协议分层的要求，描述所设计的协议，协议的设计应独立于协议实现，并且与上下层协议相对独立。
协议描述：
设计该协议的目的，基本原理
以教材上的Protocol6选择重传协议为原型，设计了此次的通讯协议，发送和接收方都维持一个窗口，从窗口中接收数据包。
接收到的数据包被缓存起来，再按正确的顺序接收完成后，呈交给网路层。
成帧方案，帧边界和转义字符的定义及转义方法
以网路层上的一个数据包为一帧，将帧打上边界，加入控制讯息后，用物理层按比特发送。
帧的边界以FLAG开头和结尾，若帧信息中包含FLAG，以转义字符ESC转换。
帧中各个字段的定义和编码，计算CRC校验和的多项式定义
帧中的第一比特为开头FLAG，第二比特是帧的类型，共定义了{data,ack,nak}frame_kind三种类型，用枚举常量表述，第三比特是顺序编码，用于确定到达帧的顺序，第四比特是ACK捎带确认讯息，记录了当前已收到帧的确认情况，这是数据帧的头部。
若为数据帧，从第五比特开始为网路层的数据，到第n+HEADLENTH比特网路层包裹信息结束后，接上4比特的CRC校验讯息，后有一结束字符FLAG表明该帧结束，此为帧的定义编码。
其中的CRC校验数据由函数crc32产生，函数crc32返回一个32位整数为数据生成CRC-32校验和，并且把这32比特校验和附在数据字节之后。
协议工作时两个站点之间信息交换的过程控制，尤其是发生误码条件下的控制方案
协议工作时，两个站点通过互发数据包交换数据，而控制讯息则稍带在数据讯息中传递，当遇到超时情况时，则主动发送空数据包以提供讯息。
当出现帧丢失时，如收到帧的序号有跳跃，或者出现CRC校验出错丢弃了某帧，会主动发送NAK否定帧，提示重传。
若长期未产生放送消息，则出现ACK
升级会员 