数据链路层滑动窗口协议实验报告
1 实验任务
对实际系统中的协议分层和协议软件的设计与实现有基本的认识。
2实验内容
利用所学数据链路层原理，自己设计一个滑动窗口协议并在仿真环境下编程实现有噪音信道环境下的 可靠的双工通信。信道模型为 8000bps 全双工卫星信道，信道传播时延 270 毫秒，信道误码率为 10-5，信道提供字节流传输服务，网络层分组长度在240~256字节范围。 通过该实验，进一步巩固和深刻理解数据链路层的字节填充方式的成帧技术，误码检测的 CRC 校验技术，以及滑动窗口的工作机理。滑动窗口机制的两个主要目标：(1) 实现有噪音信道环境下的无差错传输; (2)充分利用传输信道的带宽。在程序能够稳定运行并成功实现第一个目标之后，运行程序并检查在信道没有误码和存在误码两种情况下的信道利用率。为实现第二个目标，提高滑动窗口协议信道利用率，需要根据信道实际情况合理地为协议配置工作参数，包括滑动窗口的大小和重传定时器时限以及 ACK 搭载定时器的时限。这些参数的设计，需要充分理解滑动窗口协议的工作原理并利用所学的理论知识，经过认真的推算，计算出最优取值，并通过程序的运行进行验证。
对实际系统中的协议分层和协议软件的设计与实现有基本的认识。
3编程环境 利用仿真环境下所提供的物理层服务和定时器机制为网络层提供服务。
8.1 程序的总体结构
设数据链路层通信的两个站点分别为站点 A和站点 B，仿真环境利用WindowsXP环境下的 TCP协议和Socket客户端/服务器机制构建两个站点之间的通信，其中，站点 A为服务器端，站点 B为客户端。编译、链接之后最终生成的可执行程序(.exe文件)为字符界面命令行程序（不是图形界面程序） 。可执行程序文件仅有一份，设为 datalink.exe，在 WindowsXP 的两个 DOS 窗口中使用不同的命令行参数启动两个进程，分别仿真站点A和站点B。 8.2 实验环境所提供的文件和编译运行方法 实验环境使用Visual C++ 6.0系统
datalink.dsw， datalink.dsp： Microsoft VC6.0的工程文件，包括Win32 Debug和Win32 Release两种配置。
protocol.h：库函数中包括的函数原型以及相关的宏定义，调用库函数的 C语言源程序应当#include此文件。
datalink.c：应当由同学完成的数据链路层程序文件。许多同学C语言源程序书写格式凌乱，请参阅“附录一 源程序书写格式要求” 。
Debug/protocol.lib：Win32 Debug配置所需要的库文件。 Release/protocol.lib： Win32 Release配置所需要的库文件。
GoBackN.exe：使用搭载ACK 技术的 Go-Back-N 协议的一种参考实现，可以直接运行以了解本次实验应达到的目的。
Selective.exe：使用选择重传协议的一种参考实现。
4 协议设计
按照协议分层的要求，描述所设计的协议，协议的设计应于协议实现，并且与上下层协议相对。协议描述：
(1) 设计该协议的目的，基本原理
以教材上的Protocol 6 (Selective Repeat)选择重传协议为原型，设计了此次的通讯协议，发送和接收方都维持一个窗口，从窗口中接收数据包。接收到的数据包被缓存起来，再按正确的顺序接收完成后，呈交给网路层。
(2) 成帧方案，帧边界和转义字符的定义及转义方法
以网路层上的一个数据包为一帧，将帧打上边界，加入控制讯息后，用物理层按比特发送。帧的边界以FLAG开头和结尾，若帧信息中包含FLAG，以转义字符ESC转换。
(3) 帧中各个字段的定义和编码，计算CRC校验和的多项式定义
帧中的第一比特为开头FLAG，第二比特是帧的类型，共定义了{data,ack,nak} frame_kind三种类型，用枚举常量表述，第三比特是顺序编码，用于确定到达帧的顺序，第四比特是ACK捎带确认讯息，记录了当前已收到帧的确认情况，这是数据帧的头部。若为数据帧，从第五比特开始为网路层的数据，到第n+HEADLENTH比特网路层包裹信息结束后，接上4比特的CRC校验讯息，后有一结束字符FLAG表明该帧结束，此为帧的定义编码。 其中的CRC校验数据由函数crc32()产生，函数crc32()返回一个32位整数为数据生成CRC-32校验和，并且把这 32比特校验和附在数据字节之后。
(4) 协议工作时两个站点之间信息交换的过程控制，尤其是发生误码条件下的控制方案
协议工作时，两个站点通过互发数据包交换数据，而控制讯息则稍带在数据讯息中传递，当遇到超时情况时，则主动发送空数据包以提供讯息。
当出现帧丢失时，如收到帧的序号有跳跃，或者出现CRC校验出错丢弃了某帧，会主动发送NAK否定帧，提示重传。若长期未产生放送消息，则出现ACK超时事件，主动发送ACK帧提示确认，对方收到确认后，滑动窗口继续发送，若一直未收到确认讯息，则出现数据帧超时事件，发送方会自动重发未确认帧。
5 软件设计
给出程序的数据结构，模块之间的调用关系和功能，程序流程。
(1) 数据结构：数据结构是整个程序的要点之一，程序维护者充分了解数据结构就可以对主要算法和处理流程有个基本的理解。描述程序中自定义结构体中各成员的用途，定义的全局变量和主函数中的变量的变量名和变量所起的作用。
(2) 模块结构：给出程序中所设计的子程序所完成的功能，子程序每个参数的意义。给出子程序之间的程序调用关系图。
(3) 算法流程：画出流程图，描述算法的主要流程。 程序源代码如下： 见 源程序清单.doc
6 实验结果分析 (1) 描述你所实现的协议软件是否实现了误码信道环境中无差错传输功能
能实现，采用了CRC校验和重传技术是错误得以被发现和纠正。 (2) 程序的健壮性如何
程序健壮性强，在高负荷和高误码率等条件下均能正常工作。
(3) 协议参数的选取：滑动窗口的大小，重传定时器的时限， ACK 搭载定时器的时限，这些参数
是怎样确定的？根据信道特性数据，分组层分组的大小，以及你的滑动窗口机制，给出定量分析，
列举出选择这些参数的原因。
由于定时器数量的，窗口大小最大只能设置到，因此定时器和ACK的时限的选择就十分关键，本次实验中物理层提供了一种字节流传输服务，为了成帧， 使用了字节填充技术。分组长度为240~256字节，线路最快需要246毫秒就传输一帧，运气最不好的时候，一个256 字节分组全部充斥了需转义的字符，这样线路传输一帧，需要518毫秒左右。尽管这种极端情况很少出现，但是重传定时器的时限必须考虑这个上限，在无差错模式下，这个时限定在不太短的大小问题并不大，但在有差错的线路上，由于可能出现错须和重传，因此时限确定直接影响到线路的效率，当最初把时限定在1500时超时频率非常高，当定到一个比较高些的数字之后超时率明显下降，但若数字太大，当出现错误帧时，会影响到帧的发送效率，最后把超时时间限定在8000～12000之间，在此范围内根据不同的线路的情况选择。
(4) 理论分析：根据所设计的滑动窗口工作机制(Go-Back-N 或者选择重传)，推导出在无差错信道环
境下分组层能获得的最大信道利用率；推导出在有差错条件下分组层能获得的最大信道利用率。给出理论推导过程。理论推导的目的是得到信道利用率的极限数据。为了简化有差错条件下的最大利用率推导过程，可以对问题模型进行简化，比如：假定出现超时后一次重传可以 100%正确传输，但是简化问题分析的这些假设必须不会对整个结论产生较大的误差。
256pMAX25约为496.2%，由于信道的最由于需要携带帧讯息，因此最大的信息利用率为482505026010大比特率为8000bps，可得出每传输一个字节耗时1ms，每帧的附加讯息固定为10，耗时10ms，若出现转义字符，则可能增加时间，现在假设信道上始终有数据需要传送，这样就可以简化模型。在有的错误率的信道上，算下来在这100000个比特中可以传送100000260个数据包，则可得出8每48个数据包会有一个出错，假设每出错一次，在限定时间内可以重传该帧为正确帧。则每传送48个数据包需要传送48+1+1=50次，此时信道利用率92，而实际上由于程序设计的原因，当一个数据包超时后，往往要重复多次传输给数据包造成信道的浪费，若有k次重传，则信48250道利用率为，在此程式中，平均要重传1049k260次，因此信道利用率降为79%。 在ESC/FLAG模式中传输的平均250个字符需要两倍的传输空间即极限值500，此时的信道利用率的极限值是25048250510，而在的错误率的信道上则利用率为，若平均每个错49k510帧重传10次，利用率将下降为40%。 最后，在的信道上，出错率将提高到大约每5个帧就有一个出错，在如此高的出错率下信道利用的极限值是425062601062，当在ESC/FLAG模式下利用率的极限值425065101032，而实际的重发帧数多达10帧，此时信道利用率13%。 (5) 实验结果分析： 你的程序运行实际达到了什么样的效率， 比对理论推导给出的结论，有没有差
距？给出原因。有没有改进的办法？如果没有时间把这些方法付诸编程实施，介绍你的方案。
实验所得的结果于此大致相符： 在交替的发送的停等信道中，半停半发的端口的信道利用率自然为全利用率的50%，因此在第二行中A端的利用率约为B端的一半，这在意料之中。 表3 性能测试记录表
运行序命令 号 (秒) datalink au0 1 datalink bu0 站点A分组层平缓方式发出数datalink a0 2 datalink b0 秒，停发100秒” datalink afu0 无误码信道，站点 A和站点 B3 datalink bfu0 的分组层都洪水式产生分组 通过测试，当超时时数datalink af0 4 datalink bf0 站点A/B的分组层都洪水式产生1748.3 70.33% 73.55% 据帧会被重复多次发分组 送，占用通道资源。 datalink afs0 站点A/B分组层都洪水式产生分5 datalink bfs0 组，每分组均为 240字节 通过测试，当超时时重1543 69.73% 73.31% 发的数据帧重复过多。 通过测试，当超时时数据，站点B周期性交替“发送1001055.4 39.56% 83.96% 据帧会被重复发送。 无误码信道数据传输 280.16 62.57% 95.75% 通过测试 A B 说明 时间利用率(%) 存在的问题 接收方线路 884.3 92.84% 92.85% 通过测试 站点A/B分组层都洪水式产生分datalink afle0 组， 每分组均为 256字节长，6 datalink bfle0 分组的每个字节内容均为FLAG 或ESC字符 datalink afe0 –通过测试，超时时重发ber 1e-4 7 站点A/B的分组层都洪水式产生4326.5 18.56% 19.35% 的帧重复过多,占用的资源可观。 ber 1e-4
(6) 存在的问题：在“表3 性能测试记录表”中给出了7 种测试方案，在测试中你的程序有没有失
败，或者，虽未失败，但表现出来的性能仍有差距，你的程序中还存在哪些问题?
通过测试，当超时时重1673.3 38.04% 39.87% 发的数据帧重复过多。 datalink bfe0 –分组，线路误码率设为 10-4 该程序存在的主要问题就在于会反复重传未被确认的帧，造成了信道资源的浪费，这可以在实验的结果中看出，在进行较长时间的运行后，信道流量水平趋于平稳，此时的数据和理论之大致相当，说明所确认的问题确实是症结所在。只要能其反复重传，就能提高信道利用率。 为了解决这个问题，尝试了对协议进行了改进，使用前帧记忆识别技术，使其在超时重传时不再重复发同一帧，并改善了出错丢帧后的接受逻辑，增加ACK的发送频率，合理改善了超时时限，经过这样的改动后，预期的效果应该有所改善，但实际的效果并不明显，在信道条件较好的情况下，可以提高到接近理论值的水平如在datalink afu0 datalink bfu0的信道下，信道利用率双方都提高到了95.46%，已经很接近理论的96.2%，但在信道条件下降的情况下有时会出现死锁的情况，因此健壮性反而下降，因为窗口大小最大只有，这是硬性，在信道较差的情况下很容易就用光了，所以不适用。因此最后未被采用。
