ImageVerifierCode 换一换
格式:DOCX , 页数:9 ,大小:174.21KB ,
资源ID:15101977      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/15101977.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(数据链路层滑动窗口协议的设计与实现Word文件下载.docx)为本站会员(b****2)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

数据链路层滑动窗口协议的设计与实现Word文件下载.docx

1、该层提供服务:从网络层接受要发送的数据包,将之分拆成数据帧;按一定的成帧方案完成分帧,加校验码,加ack等操作;进行适当的流量判断和拥塞控制;启动定时器将之传递给物理层。数据帧经信道传送给接受方,接受方数据链路层执行与成帧相逆的操作;处理ack信息,终止定时器(或启动ack定时器,ack成帧传送);判断是否为欲接受数据,数据是否出错,提交给网络层。退回N步工作原理示意图:写,描述如下:1数据结构:typedefenum false,true boolean; /bloolean typetypedef unsigned char seq_nr; /sequence or ack numbers

2、typedef unsigned char packetPKT_LEN; /用数组存放数据/* FRAME kind */#define Data 1#define Ack 2#define Nak 3static intphl_ready: /物理层状态next_frame_to_send; / MAX_SEQ 1; used for outbound stream, and initianize next frame going out ack_expected; / oldest frame as yet unacknowledged, and initianize next ack e

3、xpected inbound frame_expected; / next frame expected on inbound stream, and initialize number of frame expected inbound bufferMAX_SEQ+1; / buffers for the outbound stream nbuffered; / output buffers currently in use, and initially no packets are buffered bufferLenMAX_SEQ+1 /bufferLen 存储每个buffer中数据的

4、有效长度typedefstruct /帧结构 unsigned char kind;seq_nrack;seq_nrseq;packetinfo;unsigned char crc4;frame;2模块结构:给出程序中所设计的子程序完成的功能,子程序每个参数的意义。A)static boolean between (seq_nra,seq_nrb,seq_nr c) /判断b是否是在a、c之间的帧B)static void put_frame(unsigned char *frame, intlen)/crc编码并向物理层发送C)send_data(unsigned char kind,seq

5、_nrframe_nr,seq_nrframe_expected,packet buffer,intdlen) /生成帧D)int main() / 主函数,分为五个事件(1) NETWORK_LAYER_READY,事件发生后从网络层读数据,成帧;若当前物理层可用,发送。(2) PHYSICAL_LAYER_READY,事件发生后,若有未发送的帧,发送,否则置物理层状态为可用。(3) DATA_INCOMING,事件发生后,来了arg个字节的数据,每接受一个数据,判断是否为帧尾;若为帧尾,提取一帧,去掉填充,进行校验;若校验结果正确,处理ack,然后处理数据。接受完arg个字节,跳出。(4)

6、 ACK_TIMEOUT,事件发生后,产生一个不含数据的ack帧,等待直到物理层有效,发送。(5) DATA_TIMEOUT,事件发生后,重发ack_expected和next_frame_to_send之间的帧。3算法流程:画出流程图,描述算法的主要流程。四、实验结果分析(1) 描述你所实现的协议软件是否实现了误码信道环境中无差错传输功能此协议软件实现了误码信道环境中无差错传输功能(2) 程序的健壮性在较低误码率的信道条件下,该程序运行平稳,未出现任何差错,健壮性良好,在高误码率的信道条件下,程序运行有时会出现中断,但大多数时候均运行超过二十分钟以上,故本程序健壮性良好,但仍有值得改进之处。

7、(3) 协议参数的选取:滑动窗口的大小为7,重传定时器的时限2000,ACK 搭载定时器的时限为300。在go_back_n协议中(假设接受方一直有数据发送,即无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值。滑动窗口大小的选择直接涉及到信道利用率和数

8、据拥塞的问题;若太小,会导致信道空闲,利用率很低;若太大,数据发送过快,会造成接受方数据链路层来不及处理,数据物理层及信道发生拥塞现象导致数据丢失,出错率增大,重传率高。8000kbps的信道发送256字节的帧需要 256*8/8000 = 256ms (256+270*2)/256 = 3.X,最大窗口应该7就行了.重传定时器的大小由发送速率、信道时延及接受方的发送频率等确定,太小会频繁重发,太大也会降低信道利用率。结合多项测试最终定为2000ms。ack搭载定时器的时限由本站的发送频率决定,一方面,为了节省带宽应该尽量搭载使用。另一方面当本站长时间无数据发送时应该尽量早点发送ack帧。经过

9、数项测试,定位300ms。(4) 理论分析:无差错条件下分组层能获得的最大信道利用率应该是256/262*100%=97.7,而在误码率为1e-5的情况下应为256/262(1+262*8*0.00001)=95.5。(5) 实验结果分析:你的程序运行实际达到了什么样的效率,比对理论推导给出的结论,有没有差距?给出原因。有没有改进的办法?如果没有时间把这些方法付诸编程实施,介绍你的方案。序号命令说明运行时间(秒)效率(%)备注AB1datalink audatalink bu无误码信道数据传输1957.41352.5896.972datalink adatalink b站点A分组层平缓方式发出

10、数据,站点B周期性交替“发送100秒,停发100秒”1525.15648.5787.693datalink afudatalink bfu无误码信道,站点A和B的分组层都洪水式产生分组1586.4094datalink afdatalink bf站点A/B的分组层都洪水式产生分组1899.68885.7985.805datalink af ber 1e-4datalink bf ber 1e-4站点A/B的分组层都洪水式产生分组,线路误码率设为10-41028.14938.0838.60实验成果离预期效果存在差距,尤其在有误码的条件下,信道利用率与理论之相比相差很大。原因有几个方面:填充字节和

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

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

13、dows环境和VC软件的安装问题。该实验要用vc+6.0,并且要在doc系统运行生成的exe文件。(3) 编程语言方面遇到了哪些问题?包括C语言使用和对C语言操控能力上的问题。大概没遇到什么问题。遇到的只是一些函数的调用上。(4)协议方面遇到了哪些问题?包括协议机制的设计错误,发现协议死锁,或者不能正确工作,协议参数的调整等问题。成帧时,开始我们帧结构是(ack 帧序号 数据长度 数据内容 校验和),长度在256时成了0,后来在成帧时去掉了数据长度这项。 (5) 开发库方面遇到了哪些问题?包括库程序中的BUG,库函数文档不够清楚导致误解,库函数设计在所提供的功能结构上的缺憾导致编程效率低下。这些问题或建议影响不同模块之间功能界限的划分。一开始对NETWORK_LAYER_READY和PHYSICAL_LAYER_READY理解不清晰,不明白两者各自完成什么功能。(6) 总结本次实验,你在C 语言方面,协议软件方面,理论学习方面,软件工程方面等哪些方面上有所提高?C语言方面,加深了对数组及结构定义的理解。虽然意图将结构强制转换为字符数组失败,但更了解了结构的定义和存储特点及鱼数组的区别。另

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1