北京邮电大学计算机网络第一次实验实验报告---------Selected实现班级2010211302姓名华逸群学号10211183一,实验内容和实验环境描述1.实验内容利用所学数据链路层原理，自己设计一个滑动窗口协议，在仿真环境下编程实现有噪音信道环境下两站点之间无差错双工通信。

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

通过该实验，进一步巩固和深刻理解数据链路层误码检测的CRC 校验技术，以及滑动窗口的工作机理。

滑动窗口机制的两个主要目标：(1) 实现有噪音信道环境下的无差错传输; (2)充分利用传输信道的带宽。

在程序能够稳定运行并成功实现第一个目标之后，运行程序并检查在信道没有误码和存在误码两种情况下的信道利用率。

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

这些参数的设计，需要充分理解滑动窗口协议的工作原理并利用所学的理论知识，经过认真的推算，计算出最优取值，并通过程序的运行进行验证。

2.实验环境Windows7环境PC机，Microsoft Visual C++ 6.0 集成化开发环境。

二,软件设计1.数据结构#define DATA_TIMER 2000 //数据帧重发计时时间#define ACK_TIMER 300 //发送ack帧的计时时间#define MAX_SEQ 7 //窗口大小为7struct FRAME {unsigned char kind;unsigned char ack;unsigned char seq;unsigned char data[PKT_LEN];unsigned int padding;}; //帧结构，kind为帧的类型，ack 为确认帧序号，seq为发送帧序号，data[PKL_LEN]网络层分组数据共有3种类型的帧：数据帧ack seq data crcFRAME_DATAAck帧FRAME_ACK ack crcNak帧FRAME_ACK ack crcbool no_nak = true；//判断是否有NAKarrived[NR_BUFS] = {0};//接收到的帧static unsigned char frame_nr = 0；//技术下个要传送的帧的号static unsigned char nbuffered;//已经传了多少帧static unsigned char frame_expected = 0；//希望收到的帧static unsigned char ack_expected = 0;//希望收到的确认帧static unsigned char too_far = NR_BUFS;//当前能收到的最大窗口号static unsigned char out_buf[NR_BUFS][PKT_LEN],in_buf[NR_BUFS][PKT_LEN]; //buffers for the outbound/inbound streamstatic int phl_ready = 0;//物理层是否准备好了2.模块结构static bool between (unsigned char a, unsigned char b, unsigned char c)参数：unsigned char a, b,c; //待比较的数返回值：0或者1功能：如果b循环位于ac之间。

返回1，否则返回0用途：判断接收到的ack是否在接收窗口里static void put_frame(unsigned char *frame, int len)参数：unsigned char *frame；//指向帧的指针int len；//帧长度返回值：void功能：给帧计算校验和并加在帧末尾用途：在发送帧函数中调用，用于成帧static void send_data_frame(unsigned char frame_n)参数：void返回值：void功能：从网络层获取分组，加校验和后送到物理层，并开始计时用途：用于发送数据帧static void send_ack_frame(unsigned char frame_n)参数：void返回值：void功能：发送ack帧用途：当ack计时器超时而没有数据帧发送时，发送ack帧用于应答static void send_nak_frame(void)参数：void返回值：void功能：发送nck帧用途：当没发送过nak但是又收到不是期望的帧的时候发送3.算法流程三,实验结果分析1.在有误码的情况下发送方将得不到确认,其将在数据帧计时器超时后重新发送该帧,本程序可实现有误码信道环境中无差错传输功能2.程序健壮性良好,可以持续运行并且不产生错误(3) 滑动窗口大小为63重传定时为2500msAck搭载定时350ms因为信道速率为8000bps,网络层分组大小为256Byte,信道延时270ms，一个数据帧加上帧头（3Byte）和校验和（4Byte）后大小为263Byte，数据发送时间大约为300ms，与信道延迟差不多，因此设置滑动窗口大小为7足够保证在理想情况下（网络层一直有数据）信道一直被使用且不会出现拥塞。

Ack搭载时限若太小，导致确认一直使用ack帧，降低了信道利用率，太大又会使接收方长时间得不到确认而重传数据帧，也会降低信道利用率，因此，根据网络层产生分组的情况，我们设置ack搭载时限为350ms，经过测试效果较好。

当发送方发送完一个数据帧后，若接收方一直没有分组下来，而是利用ack给发送方确认信号，一个数据帧被确认的时间为270*2+263+300+6=1109ms因此一个帧的最长确认时间为1109ms，我们设置重传定时为2500ms ,保证是帧不会被确认的情况下才开始重传，同时也保证重传时间不至太久，使信道利用率下降。

(5)1.在洪水状态下，由于需要携带帧讯息，因此最大的信息利用率为约为256/264 = 97.0%，由于信道的最大比特率为8000bps，可得出每传输一个字节耗时1ms，每帧的附加讯息固定为10，耗时10ms，若出现转义字符，则可能增加时间，现在假设信道上始终有数据需要传送，这样就可以简化模型。

10-­‐5的错误率的信道上，结果算出来应该在92.8%左右，但是我们运行结果可能没有在有到达预期的利用率。

(6) 实验结果分析：你的程序运行实际达到了什么样的效率，比对理论推导给出的结论，有没有差距？给出原因。

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

答：（性能测试表在附录2中）在洪水状态下，效率能达到96.6%，对比理论值，差距不大。

10-­‐5误码率的信道下，有很大差距，可能是ack_timer,data_timer等时间设定的问题。

在我们尝试调数据，都未得到十分满意的答案。

付诸于编程实现改动由于改动很大，未能实现。

(7) 存在的问题：在“表3 性能测试记录表”中给出了几种测试方案，在测试中你的程序有没有失败，或者，虽未失败，但表现出来的性能仍有差距，你的程序中还存在哪些问题?答：没有失败，但是性能上仍存在缺陷。

特别是在a,b与datalink af –ber 1e-4 datalink bf –ber 1e-4的时候，与老师示例数据仍有很大的差距。

四,研究和探索的问题10.1生成多项式的选择是CRC 算法实现中最重要的部分，所选择的多项式必须有最大的错误检测能力，同时保证总体的碰撞概率最小。

多项式最重要的属性是它的长度，也就是最高非零系数的数值，因为它直接影响着计算的校验和的长度。

而crc32是经常用的多项式长度，而且大量实验经验告诉我们，它的检错性能是非常好的。

如果想要增加检错性能可以再多增加校验位。

多硬件要求会更高，需要个更多的寄存器10.4start_ack_timer()和stop_ack_timer()两个定时器函数为搭载ACK 机制设置。

start_ack_timer()与start_timer()有两点不同：首先，定时器启动时刻为当前时刻；其次，在先前启动的定时器未超时之前重新执行start_ack_timer()调用，定时器将依然按照先前的时间设置产生超时事件ACK_TIMEOUT。

两种定时器不同的定时处理方式是为了适应数据链路层协议软件开发的需要。

10.6链路访问过程平衡（LAPB）是数据链路层协议，负责管理在X.25 中DTE 设备与DCE 设备之间的通信和数据包帧的组织过程。

LAPB 是源于HDLC 的一种面向位的协议，它实际上是ABM （平衡的异步方式类别）方式下的HDLC。

LAPB 能够确保传输帧的无差错和正确排序。

五,实验总结和心得体会(1)完成本次实验的实际上机调试时间是多少？答： 实际上机调试的时间大概有20个小时。

断断续续用了3天。

(2)编程工具方面遇到了哪些问题？包括Windows环境和VC软件的安装问题。

答：由于大一的时候就使用的VC++6.0的时候，所有不存在工具问题。

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

答：在调用的protocol.h的函数中遇到很多不能理解的函数调用，子函数编码的理解上遇到了问题。

可能的原因是进行了而直接的调用，同时自己对库函数不太清楚，所以很难理解。

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

答：协议上我们进行了协议五和协议六的调试与比较，在设计上先是采用了课本上原先设计的数字包括MAX_SEG,DATA_TIMER,ACK_TIMER,等，设计上并没有出现协议死锁的问题，但是在信道利用率上出现了很大的问题，就是利用率降低的很快而且在稳定阶段数字也很低，所以我们对参数进行了重新的调整，虽然不知道有没有充分的利用到信道，但是经过调整信道的利用率有所提高。

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

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

(6) 总结本次实验，你在C 语言方面，协议软件方面，理论学习方面，软件工程方面等哪些方面上有所提高？1，通过本次实验，我的C语言方面了解了更多函数的用法2，在协议方面，知道了协议书写的大致格式，更知道了书上抽象的协议怎么应用到程序中来。

3，这对于理论学习有很大的帮助，可以帮助我们更好的巩固书上过于抽象的知识，使原理真正的被我们理解。