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

数据链路层滑动窗口协议设计与实现试验汇报
一、 试验任务及内容
利用所学数据链路层原理, 设计一个滑动窗口协议并在仿真环境下编程实现有噪音信道环境下可靠双工通信。信道模型为8000bps 全双工卫星信道, 信道传输时延270 毫秒, 信道误码率为10-5, 信道提供字节流传输服务, 网络层分组长度在240~256字节范围。
(1) 实现有噪音信道环境下无差错传输。
(2) 运行程序并检验在信道没有误码和存在误码两种情况下信道利用率。
(3) 提升滑动窗口协议信道利用率, 依据信道实际情况合理地为协议配置工作参数, 包含滑动窗口大小和重传定时器时限以及ACK 搭载定时器时限。
试验环境
Windows 7环境PC机, Microsoft Visual C++ 6.0 集成化开发环境
二、 协议设计
协议分层结构及层服务:
包含物理层, 数据链路层和网络层三层。
该试验关键设计数据链路层协议, 为实现有噪声环境下高信道利用率传输, 我们采取回退n帧（go back n）技术协议。发送方窗口大小为31; 经过捎带确定来完成可靠数据通信; 出现信道误码造成收帧犯错时, 接收方丢弃全部后续帧, 待定时器超时后发送方重发。
该层提供服务: 从网络层接收要发送数据包, 将之分拆成数据帧; 按一定成帧方案完成份帧, 加校验码, 加ack等操作; 进行合适流量判定和拥塞控制 开启定时器将之传输给物理层。数据帧经信道传送给接收方, 接收方数据链路层实施与成帧相逆操作; 处理ack信息, 终止定时器（或开启ack定时器, ack成帧传送）; 判定是否为欲接收数据, 数据是否犯错, 提交给网络层。

退回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, 与IEEE802.3 以太网校验和生成多项式相同。生成多项式为:
x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x1+1
校验和附加在数据帧尾部, 接收方用带校验和数据来逻辑除以生成多项式, 余数为零则数据无误码, 反之有误码等候发送方重传。

可靠通信和误码控制方案:
经过捎带确定来完成可靠数据通信; 出现信道误码造成收帧犯错时, 接收方丢弃全部后续帧, 此时发送方长久接收不到确定信息, 引发定时器超时后发送方重发; 接收方无数据传送造成发送方无法收到捎带确定时, 接收方确定定时器超时, 结构一确定帧单独传送。

三、 软件设计
给出程序数据结构, 模块之间调用关系和功效, 程序步骤。
此次试验我们对go-back-N协议进行了编写, 描述以下:

1． 数据结构:

typedefenum {false,true} boolean; //bloolean type
typedef unsigned char seq_nr; //sequence or ack numbers
typedef unsigned char packet[PKT_LEN]; //用数组存放数据
/* FRAME kind */
#define Data 1
#define Ack 2
#define Nak 3
static 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 expected inbound
frame_expected; // next frame expected on inbound stream, and initialize number of frame expected inbound
buffer[MAX_SEQ+1]; // buffers for the outbound stream
nbuffered; // output buffers currently in use, and
initially no packets are buffered
bufferLen[MAX_SEQ+1] //bufferLen 存放每个buffer中数据有效长度
typedefstruct{ //帧结构
unsigned char kind;
seq_nrack;
seq_nrseq;
packetinfo;
unsigned char crc[4];
}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_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) ACK_TIMEOUT, 事件发生后, 产生一个不含数据ack帧, 等候直到物理层有效, 发送。
(5) DATA_TIMEOUT, 事件发生后, 重发ack_expected和next_frame_to_send之间帧。

3． 算法步骤: 画出步骤图, 描述算法关键步骤。

结束
发送完成
否
数据帧是否丢失
A生成帧并发送, B接收帧, 并返回信息
是
是
回退重传
否
连接是否成功
新建A、 B两站自动连接
开始

四、 试验结果分析
(1) 描述你所实现协议软件是否实现了误码信道环境中无差错传输功效
此协议软件实现了误码信道环境中无差错传输功效

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

(3) 协议参数选择:
滑动窗口大小为7, 重传定时器时限, 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值。滑动窗口大小选择直接包含到信道利用率和数据拥塞问题; 若太小, 会造成信道空闲, 利用率很低; 若太大, 数据发送过快, 会造成接收方数据链路层来不及处理, 数据物理层及信道发生拥塞现象造成数据丢失, 犯错率增大, 重传率高。8000kbps信道发送256字节帧需要 256*8/8000 = 256ms （256+270*2）/256 = 3.X, 最大窗口应该7就行了.
重传定时器大小由发送速率、 信道时延及接收方发送频率等确定, 太小会频繁重发, 太大也会降低信道利用率。结合多项测试最终定为ms。
ack搭载定时器时限由本站发送频率决定, 首先, 为了节省带宽应该尽可能搭载使用。其次当本站长时间无数据发送时应该尽可能早点发送ack帧。经过数项测试, 定位300ms。

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

(5) 试验结果分析: 你程序运行实际达成了什么样效率, 比对理论推导给出结论, 有没有差距？给出原因。有没有改善措施？假如没有时间把这些方法付诸编程实施, 介绍你方案。

序号
命令
说明
运行时间(秒）
效率(%)
备注
A
B
1

datalink au
datalink bu
无误码信道数据传输
1957.413
52.58
96.97

2
datalink a
datalink b
站点A分组层平缓方法发出数据, 站点B周期性交替“发送100秒, 停发100秒”
1525156
48.57
87.69

3

datalink afu
datalink bfu
无误码信道, 站点A和B分组层都洪水式产生分组
1586.409
96.97
96.97

4
datalink af
datalink bf
站点A/B分组层都洪水式产生分组
1899.688
85.79
85.80

5

datalink af –ber 1e-4
datalink bf –ber 1e-4
站点A/B分组层都洪水式产生分组, 线路误码率设为10-4
1028.149
38.08
38.60

试验结果离预期效果存在差距 尤其在有误码条件下, 信道利用率与理论之相比相差很大。原因有多个方面: 填充字节和发送时候延迟, 这首先无法缩短; 信道空闲, 只是因为窗口大小、 重传定时器时限和ACK 搭载定时器时限选择不是很合适, 这方面, 需要多做测试来确定发送端、 接收端延时, 再确定具体数值; 另外, ack发送可能有些滞后, 没有一个非常合剪发送机制。
还有一点, 从网络层受到数据后, 我是把数据成帧后存起来, 现在看来, 考虑到ack更新, 在发送时再成帧更有效率些。

(6) 存在问题: 在“表3 性能测试统计表”中给出了7 种测试方案, 在测试中你程序有没有失败, 或者, 虽未失败, 但表现出来性能仍有差距, 你程序中还存在哪些问题?
测试中没有失败, 不过性能差距挺大。关键是超时时限和窗口大小问题。

五、 研究和探索问题
1．start_timer()不是在开启时就计时, 而是在物理层发送了才开始计时; 相对, start_ack_timer()是以开启就开始计时。前者要考虑发送缓冲区等候时间, 以后者考虑是ack是否被装到了帧上。
2．重传时限设定得比较长, 大部分情况下都不会超时。实践证实, 这种情况下效率相对更高一点。
3．流量控制方面, 首先窗口大小能够控制。然后发送和接收缓存区大小也限制了流量。

六、 试验总结和心得体会

(1) 完成此次试验实际上机调试时间是多少？
三天, 第一天花了大约7小时讨论程序结构以及函数调用, 第二天完成编程并调试, 第三天写文档和性能测试,

(2) 编程工具方面碰到了哪些问题？包含Windows环境和VC软件安装问题。
该试验要用vc++6.0, 而且要在doc系统运行生成exe文件。

(3) 编程语言方面碰到了哪些问题？包含C语言使用和对C语言操控能力上问题。
大约没碰到什么问题。。碰到只是部分函数调用上。

(4)协议方面碰到了哪些问题？包含协议机制设计错误, 发觉协议死锁, 或者不能正确工作, 协议参数调整等问题。
成帧时, 开始我们帧结构是(ack 帧序号 数据长度 数据内容 校验和), 长度在256时成了0, 以后在成帧时去掉了数据长度这项。

(5) 开发库方面碰到了哪些问题？包含库程序中BUG, 库函数文档不够清楚造成误解, 库函数设计在所提供功效结构上缺憾造成编程效率低下。这些问题或提议影响不一样模块之间功效界限划分。
一开始对NETWORK_LAYER_READY和PHYSICAL_LAYER_READY了解不清楚, 不明白二者各自完成什么功效。
(6) 总结此次试验, 你在C 语言方面, 协议软件方面, 理论学习方面, 软件工程方面等哪些方面上有所提升？
C语言方面, 加深了对数组及结构定义了解。即使意图将结构强制转换为字符数组失败, 但更了解了结构定义和存放特点及鱼数组区分。另外是培养良好编程风格是很关键, 在一个结构比较复杂程序中, 有意义变量命名能让人理清条理, 愈加好掌握总体框架; 而清楚格式便于差错。
协议软件方面, 了解了通用性关键。一开始光顾着思索自己写东西, 忘了搞清老师给函数、 参数等, 很费了一番力气。开始没有太明白NETWORK_LAYER_READY和PHYSICAL_LAYER_READY意义, 卡了很长一段时间。编写协议软件, 很关键一步是搞清接口函数和参数用途, 注意通用性。还有协议软件要有高效性和健壮性, 不然没有使用价值。
经过自己编写一个协议, 自己对协议本身了解也加深了。愈加深入把握了协议性质, 其实不一样协议基础目, 实现过程都有一定相同性。这对学习其她协议也有很大好处。
学会了怎样增加效益。比如搭载ack协议中, 两边都连续发和一边发发停停情况下, 前者在ack超时时限长时候效益更高, 以后者在时限短时候愈加好, 要使双方都达成一个比较理想数值, 就要找到一个中间值。这是件很费时事情。