当参数为f –ber 5e-5时程序运行效果如下：
当参数为f –ber 5e-4时候的运行效果如下：
当参数为f –ber 1e-4的时候运行效果如下：
该程序存在的主要问题就在于会反复重传未被确认的帧，造成了信道资源的浪费，这可以在实验的结果中看出，在进行较长时间的运行后，信道流量水平趋于平稳，此时的数据和
理论之大致相当，说明所确认的问题确实是症结所在。只要能限制其反复重传，就能提高信道利用率。
11.5 研究和探索的问题
前面列出的“可研究和探索的问题”，有哪些问题你有了答案或者自己的见解？给出你的结论，并详细阐述你的理由或见解。
1. CRC 校验能力
CRC校验码的检错能力很强，它除了能检查出离散错外，还能检查出突发错，CRC校验码具有以下检错能力：CRC校验码能检查出全部单个错；CRC校验码能检查出全部离散的二位错；CRC校验码能检查出全部奇数个错；CRC校验码能检查出全部长度小于或等于K位的突发错；CRC校验码能以[1-（1/2）K-1]的概率检查出长度为（K+1）位的突发错。
2. 软件测试方面的问题
(1)验证所完成的程序能否在各种情况下都能够正确工作，是软件测试环节的主要目的。 (2)表3 中列出了七种测试方案，设计这么多种测试方案的目的是检测此程序在不同信道条件下的传输性能。
-u是测试成帧方案的效率。无参数时模拟在实际线路中，不连续的收发时的传输性能。-f用于测试信道满负荷时的传输性能。-l,-e,-s用于测试在特殊情境下传输性能。-ber可以改变误码率，从而检验无差错传输的健壮性及性能。 11.6 实验总结和心得体会
如果一切100%顺利，编辑的程序一次编译就通过，运行一次就正确，那么完成本次实验的代码编写和调试工作大约需要4~6 个小时。你花的时间超过了这个预测吗？描述在调试过程中都遇到了哪些问题和解决的过程。
(1) 完成本次实验的实际上机调试时间是多少？
五天，总共约十五个小时。
(2) 编程工具方面遇到了哪些问题？包括Windows环境和VC软件的安装问题。
无。
(3) 编程语言方面遇到了哪些问题？包括C语言使用和对C语言操控能力上的问题。 实验中数据帧采用了字符数组这种数据结构，在函数调用时会用到数组的形参表示，由
于需要改变数组的值，此时传送的是数组首地址，属于传引用调用。
(4) 协议方面遇到了哪些问题？包括协议机制的设计错误，发现协议死锁，或者不能正确工作，协议参数的调整等问题。
在确定成帧方案时，有两种可以实现的方案：一种是先给数据加CRC校验码，再添加ESC字符成帧 ；另一种是先给数据加ESC，再CRC校验，再给CRC加ESC。其中后者先给数据加操作实现较为复杂，但其检错性能更好，前者处理较为简单，但检错性能稍弱.我们将两种方法均加以实现之后，发现实际的效果差别不大，为了代码简介以及减少不必要变量的使用，我们在最终的程序中使用了先加ESC后CRC校验方法。
(6) 总结本次实验，你在C 语言方面，协议软件方面，理论学习方面，软件工程方面等哪些方面上有所提高？
在这次实验过程中，我们遇到了较多困难，实际编程调试的时间超出了预期，主要原因是在于我们对go-back-N协议理解得不够透彻所致，同时对本次实验所提供的实验平台也不够熟悉，前期熟悉该实验平台的工作模式也花费了一部分的时间。
在实际编程过程中，我们采用了由简到繁，逐步推进的策略，先编写一个最简单一个窗口的停等协议，在慢慢复杂化，编写go-back-N协议。在编写停等协议阶段，我们按照分组成帧，crc校验，定时器重传，ack定时器的顺序编写。由于对窗口数目和缓冲区数目这两个概念的混淆，以及一开始没有很好的明确算法及相应流程，使我们花费了相当长的时间才达到了实现停等协议的目的。在这个过程中，我们解决了关于数据成帧和crc的校验问题。
在实现了停等协议之后，我们扩大了缓冲区的数目，着手进行go-back-N协议的编写。在这个阶段，我们主要解决了超时重传和缓冲区数据发送以及ack发送问题、缓冲区数据发送问题。
上面便是我们此次实验的一个大体流程，其实在实验过程中，我们还遇到了其他的问题。经过和组员的一起讨论和对程序的大量调试和运行，最终解决问题和完成任务，同时更为重要的是，通过本次实验，我们对go-back-N这一协议的运作过程有了更为深刻的理解。 11.7 源程序清单
按照附录一“源程序书写格式”要求的源程序书写规范，格式化你的C 语言源程序。源程序打印必须采用Word 格式电子版文件“源程序清单.DOC”规定的字体大小和样式，填写好姓名，学号等相关内容，将程序粘贴到文件中替换原源程序内容，以横版双列打印在A4 打印纸上，装订在实验报告的最后。