数据链路层滑动窗口协议的设计和实现样本

数据链路层滑动窗口协议的设计和实现样本数据链路层滑动窗口协议的设计和实现本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

数据链路层滑动窗口协议的设计与实现实验报告
一、实验任务及内容利用所学数据链路层原理，设计一个滑动窗口协议并在仿真环境下编程实现有噪音信道环境下的可靠的双工通信。

信道模型为8000bps全双工卫星信道，信道传播时延270毫秒，信道误码率为10--55，信道提供字节流传输服务，网络层分组长度在240~256字节范围。

(1)实现有噪音信道环境下的无差错传输。

(2)运行程序并检查在信道没有误码和存在误码两种情况下的信道利用率。

(3)提高滑动窗口协议信道利用率，根据信道实际情况合理地为协议配置工作参数，包括滑动窗口的大小和重传定时器时限以及ACK搭载定时器的时限。

实验环境Windows7环境PC，机，Microsoft VisualC++集成化开发环境
二、协议设计协议的分层结构及层服务::包括物理层，数据链路层和网络层三层。

该实验主要设计数据链路层协议，为实现有噪声环境下高信道利用率传输，我们采用回本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

退n n帧（go backn）技术的协议。

发送方窗口大小为31；通过捎带确认来完成可靠的数据通信；出现信道误码导致收帧出错时，接受方丢弃所有后续帧，待定时器超时后发送方重发。

该层提供服务::从网络层接受要发送的数据包，将之分拆成数据帧；按一定的成帧方案完成分帧，加校验码，加ack等操作；进行适当的流量判断和拥塞控制；启动定时器将之传递给物理层。

数据帧经信道传送给接受方，接受方数据链路层执行与成帧相逆的操作；处理ack信息，终止定时器（或启动ack定时器，ack成帧传送）；判断是否为欲接受数据，数据是否出错，提交给网络层。

退回N N步工作原理示意图::本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

实验所形成帧((成帧方案))::DATA
Framen+=========+========+========+===============+======== +|KIND
(1)|ACK
(1)|SEQ
(1)|DATA(240~256)|CRC
(4)||+=========+========+========+===============+========+ ACK Frame+=========+========+========+|KIND
(1)|ACK
(1)|CRC
(4)|+=========+========+========+NAK
Frame+=========+========+========+|KIND
(1)|ACK
(1)|CRC
(4)|+=========+========+========+本文档所提供的信息仅供
参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

CRC校验和的多项式定义::本次实验采用的CRC校验方案为
CRC--32，以太网校验和生成多项式相同。

生成多项式为::x x32+x26+x23+x22+x16+x12+x11+x10++x
x88+x77+x55+x44+x22+x11+1校验和附加在数据帧，尾部，接受方用带校验和的数据来逻辑除以生成多项式，余数为零则数据无误码，反之有误码等待发送方重传。

可靠通信和误码控制方案::通过捎带确认来完成可靠的数据通信；出现信道误码导致收帧出错时，接受方丢弃所有后续帧，此时发送方长久接受不到确认信息，引发定时器超时后发送方重发；接受方无数
据传送导致发送方无法收到捎带确认时，接受方确认定时器超时，构造一确认帧单独传送。

三、软件设计给出程序的数据结构，模块之间的调用关系和功能，程序流程。

本次实验我们对go--back--N N协议进行了编写，描述如下::本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

11．．数据结构::typedefenum{false,true}boolean;//bloolean typetypedef unsigned char seq_nr;//sequence orack numberstypedef unsigned char packet[PKT_LEN];//用数组存放数据/*FRAME kind*/#define Data1#define Ack2#define Nak3static intphl_ready:://物理层状态next_frame_to_send;//M MAAX X__S SEEQ Q本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

>>11;u usse edd f fo orr oou uttb boou unnd d本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

s sttr reea amm,a annd di inni itti ia an niiz zee本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

n neex xtt ffr raam mee ggo oiin ngg oou utt本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

ack_expected;//oldest frameas yetunacknowledged,and initianni izene本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

xt ackexpected inboundframe_expected;//next frame expected on本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

inbound stream,and initializenumber offrameex本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

pected inboundbuffer[MAX_SEQ+1];//bu ffersfor theoutbound streamnbuffered;//output bufferscurrently inuse,and initt iallyno packetsare bufferedbufferLen[MAX_SEQ+1]//bufferLen
存储每个r buffer中数据的有效长度typedefstruc t{//帧结构unsigned charkind;seq_nrack;seq_nrseq;packetinfo;本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

unsigned charcrc[4];}frame;;22．．模块结构::给出程序中所设计的子程序。

完成的功能，子程序每个参数的意义。

A)static booleanbetween(seq_nra,seq_nrb,seq_nr c)//判断b b是否是在aa、c c之间的帧B)static
voidput_frame(unsignedchar*frame,intlen)//c crc编码并向物理层发送
C)send_data(unsignedcharkind,seq_nrframe_nr,seq_nrframe_exp ected,packet buffer[],intdlen[])//生成帧D)int main()//主函数，分为五个事件
(1)NETWORK_LAYER_READY，事件发生后从网络层读数据，成帧；若当前物理层可用，发送。

(2)PHYSICAL_LAYER_READY，事件发生后，若。

有未发送的帧，发送，否则置物理层状态为可用。

本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

(3)DATA_INING，事件发生后，来了arg个字节的数据，每接受一个数据，判断是否为帧尾；若为帧尾，提取一帧，去掉填充，进行校验；若校验结果正确，处理ack，然后处理数据。

接受完arg个字节，跳出。

(4)ACK_TIMEOUT，事件发生后，产生一个不含数据的ack帧，等待直到物理层有效，发送。

(5)DATA_TIMEOUT，事件发生后，重发ack_expected和
next_frame_to_send。

之间的帧。

33．．算法流程::画出流程图，描述算法的主要流程。

本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

四、实验结果分析
(1)描述你所实现的协议软件是否实现了误码信道环境中无差错
传输功能此协议软件实现了误码信道环境中无差错传输功能本文档
所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

(2)程序的健壮性在较低误码率的信道条件下，该程序运行平稳，未出现任何差错，健壮性良好，在高误码率的信道条件下，程序运行有时会出现中断，但大多数时候均运行超过二十分钟以上，故本程序健壮性良好，但仍有值得改进之处。

(3)协议参数的选取::滑动窗口的大小为77，重传定时器的时限，ACK搭载定时器的时限为300。

在在n go_back_n协议中（假设接受方一直有数据发送，即无k ack 定时器超时现象），滑动窗口的大小M,信道传输时延a,发送速率c c，帧大小ff在满足如下关系时信道利用率（M*(f/c)/[2a+2(f/c)]）接近100%:M>=[2a+2*(f/c)]/（f/c）;;由于实际数据传送很可能在某段时间类接受方无数据反送，涉及及k ack帧单独传送问题，故一般信道利用率不可能达到100%，但M M的选择至少要满足公式。

至于防止M M过大的问题，可通过实际测试的结果分析来得到合适的M M。

值。

滑动窗口大小的选择直接本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

涉及到信道利用率和数据拥塞的问题；若太小，会导致信道空闲，利用率很低；若太大，数据发送过快，会造成接受方数据链路层来不及处理，数据物理层及信道发生拥塞现象导致数据丢失，出错率增大，重传率高。

s8000kbps的信道发送256字节的帧需要256*8/8000=256ms （256+270*2））/256=，，最大窗口应该77就行了..重传定时器的大小由发送速率、信道时延及接受方的发送频率等确定，太小会频繁重发，太大也会降低信道利用率。

结合多项测试最终定为ms。

ack搭载定时器的时限由的发送频率决定，一方面，为了节省带宽应该尽量搭载使用。

另一方面当长时间无数据发送时应该尽量早点发送ack帧。

经过数项测试，定位300ms。

(4)理论分析::无差错条件下分组层能获得的最大信道利用率应该是256/262*100%=，而在误码率为1e--55的情况下应为256/262（1+262*8*）==。

(
(55))实验结果分析::你的程序运行实际达到了什本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

么样的效率，比对理论推导给出的结论，有没有差距??给出原因。

有没有改进的办法??如果没有时间把这些方法付诸编程实施，介绍你的方案。

序号命令说明运行时间(秒）效率(%)备注A B1datalink audatalink bu无误码信道数据传输1957.41352.5896.972datalink adatalink b点站点A分组层平缓方式发出点数据，站点B周期性交替送“发送100发秒，停发100秒”1525.15648.5787.693datalink afudatalink bfu无误码信道，点站点A和B的分组层都洪水式产生分组1586.40996.9796.974datalink afdatalink bf点站点A/B的分组层都洪水式产生分组1899.68885.7985.805datalink af–
ber1e-4datalink bf–ber1e-4点站点A/B的分组层都洪水式产生分组，线路误码率设为为10-41028.14938.0838.60实验成果离预期效果存在差距，，特别在有误码的条件下，信道利用率与理论之相比相差很大。

原因有几个方面::填充字节和发送时候的延迟，这一方面无法缩短；信道空闲，只是因为窗口大小、重传定时器的时限和ACK搭载定时器的本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

时限的选择不是很恰当，这方面，需要多做测试来确定发送端、接收端的延时，再确定具体数值；另外，ack的发送可能有些滞后，没有一个非常合理的发送机制。

还有一点，从网络层受到数据后，我是把数据成帧后存起来的，现在看来，考虑到ack的更新，在发送时再成帧更有效率些。

(6)存在的问题::在“表3性能测试记录表”中给出了7种测试方案，在测试中你的程序有没有失败，或者，虽未失败，但表现出来的性能仍有差距，你的程序中还存在哪些问题??测试中没有失败，不过性能差距挺大。

主要是超时时限和窗口大小的问题。

五、研究和探索的问题11．start_timer()不是在启动时就计时，而是在物理层发送了才开始计时；相对的，start_ack_timer()是以启动就开始计时。

前者要考虑发送缓冲区的等待时间，而后者考虑的是ack是否被装到了帧上。

本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

22．重传时限设定得比较长，大部分情况下都不会超时。

实践证明，这种情况下效率相对更高一点。

33．流量控制方面，首先窗口的大小能够控制。

然后发送和接收缓存区的大小也限制了流量。

六、实验总结和心得体会
(1)完成本次实验的实际上机调试时间是多少??三天，第一天花了大概77小时讨论程序结构以及函数的调用，第二天完成编程并调试，第三天写文档和性能测试，
(2)编程工具方面遇到了哪些问题??包括Windows环境和VC软件的安装问题。

该实验要用vc++，并且要在doc系统运行生成的exe文件。

(3)编程语言方面遇到了哪些问题??包括C C语言使用和对C C语言操控能力上的问题。

大概没遇到什么问题。

遇到的只是一些函数的调用上。

本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

(4))协议方面遇到了哪些问题??包括协议机制的设计错误，发现协议死锁，或者不能正确工作，协议参数的调整等问题。

成帧时，开始我们帧结构是(ack帧序号数据长度数据内容校验和))，长度在6256时成了00，后来在成帧时去掉了数据长度这项。

(5)开发库方面遇到了哪些问题??包括库程序中的BUG，库函数文档不够清楚导致误解，库函数设计在所提供的功能结构上的缺憾导致编程效率低下。

这些问题或建议影响不同模块之间功能界限的划分。

一开始对NETWORK_LAYER_READY和PHYSICAL_LAYER_READY理解不清晰，不明白两者各自完成什么功能。

(6)总结本次实验，你在C语言方面，协议软件方面，理论学习方面，软件工程方面等哪些方面上有所提高??C C语言方面，加深了对数组及结构定义的理解。

虽然意图将结构强制转换为字符数组失败，但更了解了结构的定义和存储特点及鱼数组的本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

区别。

另外是培养良好的编程风格是很重要的，在一个结构比较复杂的程序中，有意义的变量命名能让人理清条理，更好的掌握总体框架；而清楚的格式便于差错。

协议软件方面，了解了通用性的重要。

一开始光顾着思考自己写的东西，忘了弄清老师给的函数、参数等，很费了一番力气。

开始没有太明白NETWORK_LAYER_READY和Y
PHYSICAL_LAYER_READY的意义，卡了很长一段时间。

编写协议软件，很重要的一步是弄清接口函数和参数的用途，注意通用性。

还有协议软件要有高效性和健壮性，否则没有使用价值。

通过自己编写一个协议，自己对协议本身的理解也加深了。

更加深入的把握了协议的性质，其实不同的协议基本目的，实现过程都有一定的相似性。

这对学习其它协议也有很大的好处。

学会了如何增加效益。

比如搭载k ack的协议中，两边都连续发和一边发发停停的情况下，前者在k ack超时的时限长的时候效益更高，而后者在时限短的时候更好，要使双方都达到一个比较理想的数值，就要找到一个中间值。

这是件很费时的事情。

本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。

内容仅供参考。