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

《数据链路层滑动窗口协议的设计与实现》由会员分享，可在线阅读，更多相关《数据链路层滑动窗口协议的设计与实现（7页珍藏版）》请在装配图网上搜索。

1、数据链路层滑动窗口协议的设计与实现实验报告-、实验任务及内容利用所学数据链路层原理，设计一个滑动窗口协议并在仿真环境下编程实现有噪音信道 环境下的可靠的双工通信。信道模型为8000bps全双工卫星信道，信道传播时延270毫秒， 信道误码率为10占信道提供字节流传输服务，网络层分组长度在240256字节范围。(1) 实现有噪音信道环境下的无差错传输。(2) 运行程序并检查在信道没有误码和存在误码两种情况下的信道利用率。(3) 提高滑动窗口协议信道利用率，根据信道实际情况合理地为协议配置工作参数，包括滑 动窗口的大小和重传定时器时限以及ACK搭载定时器的时限。实验环境Windows 7 环境 PC

2、 机，Microsoft Visual C+ 6.0 集成化开发环境二、协议设计协议的分层结构及层服务：包括物理层，数据链路层和网络层三层。该实验主要设计数据链路层协议，为实现有噪声环境下高信道利用率传输，我们采用 回退口帧(go back n)技术的协议。发送方窗口大小为31；通过捎带确认来完成可靠的数 据通信；出现信道误码导致收帧出错时，接受方丢弃所有后续帧，待定时器超时后发送方 重发。该层提供服务：从网络层接受要发送的数据包，将之分拆成数据帧；按一定的成帧方 案完成分帧，加校验码，力口ack等操作；进行适当的流量判断和拥塞控制；启动定时器将 之传递给物理层。数据帧经信道传送给接受方，接受

3、方数据链路层执行与成帧相逆的操作； 处理ack信息，终止定时器(或启动ack定时器，ack成帧传送)；判断是否为欲接受数据， 数据是否出错，提交给网络层。退回N步工作原理示意图:讣时器超时一|( 引亍012-3 4i567S 236小910发迭方发送帧接受方接收帧岀错时问实验所形成帧(成帧方案):DATA Framen+=+=+=+=+=+ | KIND(1) | ACK(1) | SEQ(1) | DATA(240256) | CRC(4) | +=+=+=+=+=+ACK Frame+=+=+=+| KIND(1) | ACK(1) | CRC(4) |+=+=+=+NAK Frame+=

4、+=+=+| KIND(1) | ACK(1) | CRC(4) |+=+=+=+CRC校验和的多项式定义：本次实验采用的CRC校验方案为CRC-32,与IEEE802.3以太网校验和生成多项式相同。 生成多项式为：x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x1+1 校验和附加在数据帧尾部,接受方用带校验和的数据来逻辑除以生成多项式,余数为零则 数据无误码,反之有误码等待发送方重传。可靠通信和误码控制方案：通过捎带确认来完成可靠的数据通信；出现信道误码导致收帧出错时,接受方丢弃所 有后续帧,此时发送方长久接受不到确认信息,引发定时器超时后发送

5、方重发；接受方无 数据传送导致发送方无法收到捎带确认时,接受方确认定时器超时,构造一确认帧单独传 送。三、软件设计给出程序的数据结构,模块之间的调用关系和功能,程序流程 本次实验我们对go-back-N协议进行了编写，描述如下：1数据结构：typedefenum false,true boolean; typedef unsigned char seq_nr; typedef unsigned char packetPKT_LEN; /* FRAME kind */bloolean type/sequence or ack numbers/用数组存放数据#define Data 1#defin

6、e Ack 2#define Nak 3 static intphl_ready：/物理层状态next_frame_to_send;/ MAX_SEQ 1; used for outbound stream, andack_expected;frame_expected;bufferMAX_SEQ+1; nbuffered;bufferLenMAX_SEQ+1 typedefstructunsigned char kind;seq_nrack;seq_nrseq; packetinfo;unsigned char crc4;frame;initianize next frame going o

7、ut/ oldest frame as yet unacknowledged, and initianize next ack expected inbound/ next frame expected on inbound stream, and initialize number of frame expected inbound/ buffers for the outbound stream/ output buffers currently in use, and initially no packets are buffered/bufferLen存储每个buffer中数据的有效长

8、度 /帧结构2模块结构：给出程序中所设计的子程序完成的功能，子程序每个参数的意义。A) static boolean bet ween (seq_nra,seq_nrb,seq_nr c) /判断b是否是在a、c 之间的帧B) static void put_frame(unsigned char *frame, intien)/crc 编码并向物理层发送C) send_data(unsignedchar kind,seq_nrframe_nr,seq_nrframe_expected,packetbuffer,intdlen)/生成帧D) int main()/主函数，分为五个事件(1) N

9、ETWORK_LAYER_READY,事件发生后从网络层读数据，成帧；若当前物理层可用，发送。(2) PHYSICAL_LAYER_READY,事件发生后，若有未发送的帧，发送，否则置物理层状态为 可用。(3) DATA_INCOMING，事件发生后，来了 arg个字节的数据，每接受一个数据，判断是否为 帧尾；若为帧尾，提取一帧，去掉填充，进行校验；若校验结果正确，处理ack，然后处理 数据。接受完arg个字节，跳出。(4) ACK_TIMEOUT,事件发生后，产生一个不含数据的ack帧，等待直到物理层有效，发送。(5) DATA_TIMEOUT，事件发生后，重发 ack_expec ted和

10、nex t_frame _t o_send之间的帧。3算法流程：画出流程图，描述算法的主要流程。新建A、B两站自动连四、实验结果分析(1) 描述你所实现的协议软件是否实现了误码信道环境中无差错传输功能 此协议软件实现了误码信道环境中无差错传输功能(2) 程序的健壮性 在较低误码率的信道条件下，该程序运行平稳，未出现任何差错，健壮性良好，在高误 码率的信道条件下，程序运行有时会出现中断，但大多数时候均运行超过二十分钟以上，故 本程序健壮性良好，但仍有值得改进之处。(3) 协议参数的选取：滑动窗口的大小为7,重传定时器的时限2000, ACK搭载定时器的时限为300。在go_back_n协议中(假

11、设接受方一直有数据发送，即无ack定时器超时现象)，滑动 窗口的大小M,信道传输时延a,发送速率c,帧大小f在满足如下关系时信道利用率(M*(f/c)/2a+2(f/c)接近100%:M=2a+2*(f/c)/ (f/c);由于实际数据传送很可能在某段时 间类接受方无数据反送，涉及ack帧单独传送问题，故一般信道利用率不可能达到100%， 但M的选择至少要满足公式。至于防止M过大的问题，可通过实际测试的结果分析来得到 合适的 M 值。滑动窗口大小的选择直接涉及到信道利用率和数据拥塞的问题；若太小，会 导致信道空闲，利用率很低；若太大，数据发送过快，会造成接受方数据链路层来不及处理， 数据物理层

12、及信道发生拥塞现象导致数据丢失，出错率增大，重传率高。8000kbps的信道 发送 256 字节的帧需要 256*8/8000 = 256ms (256+270*2) /256 = 3.X,最大窗口应该 7 就行了.重传定时器的大小由发送速率、信道时延及接受方的发送频率等确定，太小会频繁重 发，太大也会降低信道利用率。结合多项测试最终定为2000ms。ack搭载定时器的时限由本站的发送频率决定，一方面，为了节省带宽应该尽量搭载使 用。另一方面当本站长时间无数据发送时应该尽量早点发送ack帧。经过数项测试，定位 300ms。(4) 理论分析：无差错条件下分组层能获得的最大信道利用率应该是256/

13、262*100%=97.7，而在误码率 为le-5的情况下应为256/262(1+262*8*0.00001)=95.5。(5) 实验结果分析：你的程序运行实际达到了什么样的效率，比对理论推导给出的结论，有 没有差距？给出原因。有没有改进的办法？如果没有时间把这些方法付诸编程实施，介绍 你的方案。序命令号1 datali nk au datali nk bu2 datali nk a datali nk b3 datali nk afu datali nk bfu说明无误码信道数据传输运行时间(秒)1957.413站点A分组层平缓方式发出1525.156 数据，站点B周期性交替“发送100秒，

14、停发100秒”无误码信道，站点A和B的1586.409分组层都洪水式产生分组效率（）备注AB 52.5896.9748.5796.9787.6996.974datali nk af datali nk bf站点A/B的分组层都洪水式 产生分组1899.68885.7985.805datalink af -ber 1e-4 datalink bf -ber 1e-4站点A/B的分组层都洪水式 产生分组，线路误码率设为10-41028.14938.0838.60实验成果离预期效果存在差距，尤其在有误码的条件下，信道利用率与理论之相比相差 很大。原因有几个方面：填充字节和发送时候的延迟，这一方面无法

15、缩短；信道空闲，只是 因为窗口大小、重传定时器的时限和ACK搭载定时器的时限的选择不是很恰当，这方面，需要多做测试来确定发送端、接收端的延时，再确定具体数值；另外，ack的发送可能有些 滞后，没有一个非常合理的发送机制。还有一点，从网络层受到数据后，我是把数据成帧后存起来的，现在看来，考虑到ack 的更新，在发送时再成帧更有效率些。(6) 存在的问题：在“表3 性能测试记录表”中给出了7 种测试方案，在测试中你的程序有 没有失败，或者，虽未失败，但表现出来的性能仍有差距，你的程序中还存在哪些问题?测试中没有失败，不过性能差距挺大。主要是超时时限和窗口大小的问题。五、研究和探索的问题1. st

16、ar t_t imer()不是在启动时就计时，而是在物理层发送了才开始计时；相对的，st ar t_ack_ ti mer()是以启动就开始计时。前者要考虑发送缓冲区的等待时间，而后者考虑 的是ack是否被装到了帧上。2. 重传时限设定得比较长，大部分情况下都不会超时。实践证明，这种情况下效率相对更 高一点。3. 流量控制方面，首先窗口的大小可以控制。然后发送和接收缓存区的大小也限制了流量。六、实验总结和心得体会(1) 完成本次实验的实际上机调试时间是多少？ 三天，第一天花了大概7小时讨论程序结构以及函数的调用，第二天完成编程并调试，第 三天写文档和性能测试， 编程工具方面遇到了哪些问题？包括

17、Windows环境和VC软件的安装问题。该实验要用vc+6.0,并且要在doc系统运行生成的exe文件。 编程语言方面遇到了哪些问题？包括C语言使用和对C语言操控能力上的问题。 大概没遇到什么问题。遇到的只是一些函数的调用上。(4) 协议方面遇到了哪些问题？包括协议机制的设计错误，发现协议死锁，或者不能正确工 作，协议参数的调整等问题。成帧时，开始我们帧结构是(ack帧序号数据长度数据内容校验和)，长度在256时 成了 0，后来在成帧时去掉了数据长度这项。(5) 开发库方面遇到了哪些问题？包括库程序中的BUG,库函数文档不够清楚导致误解，库 函数设计在所提供的功能结构上的缺憾导致编程效率低下。

18、这些问题或建议影响不同模块 之间功能界限的划分。一开始对NETWORK_LAYER_READY和PHYSICAL_LAYER_READY理解不清晰，不明白两者各 自完成什么功能。(6) 总结本次实验，你在C语言方面，协议软件方面，理论学习方面，软件工程方面等哪些 方面上有所提高？C 语言方面，加深了对数组及结构定义的理解。虽然意图将结构强制转换为字符数组失 败，但更了解了结构的定义和存储特点及鱼数组的区别。另外是培养良好的编程风格是很重 要的，在一个结构比较复杂的程序中，有意义的变量命名能让人理清条理，更好的掌握总体 框架；而清楚的格式便于差错。协议软件方面，了解了通用性的重要。一开始光顾着思

19、考自己写的东西，忘了弄清老师 给的函数、参数等，很费了一番力气。开始没有太明白 NETWORK_LAYER_READY 和 PHYSICAL_LAYER_READY 的意义，卡了很长一段时间。编写协议软件，很重要的一 步是弄清 接口函数和参数的用途，注意通用性。还有协议软件要有高效性和健壮性，否则没有使用价 值。通过自己编写一个协议，自己对协议本身的理解也加深了。更加深入的把握了协议的性 质，其实不同的协议基本目的，实现过程都有一定的相似性。这对学习其他协议也有很大的 好处。学会了如何增加效益。比如搭载 ack 的协议中，两边都连续发和一边发发停停的情况下， 前者在ack超时的时限长的时候效益更高，而后者在时限短的时候更好，要使双方都达到一 个比较理想的数值，就要找到一个中间值。这是件很费时的事情。