计算机网络数据链路层的实验报告(2)

6. 实验结果分析（Go-Back-N）（1）MAX_SEQ的最佳值为7，效率太低，饱和度太大，并且在物理层中有过多的累积. （2）DATA_TIMER的最佳值为3000. 此参数的选择涉及相应的重传时间. 如果时间更改太大，将导致重发等待时间过长. 如果时间太短，将导致相对较长的时间. 频繁的重传，两种情况都会导致信道利用率下降. （可选）23/27计算机网络实验和报告（1）MAX_SEQ的最佳值为15，效率太低，饱和度太大，并且过多的电荷在物理层中累积. （2）DATA_TIMER的最佳值为3000. 此参数的选择涉及相应的重传时间. 如果时间更改太大，将导致重发等待时间过长. 如果时间太短，将导致相对较长的时间. 频繁的重传，两种情况都会导致信道利用率下降. （3）ACK_TIMER的最佳值为240. 如果该值太小，则频繁重发ack帧将降低信道利用率. 如果该值设置得太大，则发送者将长时间获得ack确认信号. 会引起重传并降低利用率. 七，研究与探索问题CRC校验能力Q: 假设本实验中设计的协议使用通信系统来构建. 这种“在错误通道上实现无错误传输”功能听起来是错误的，但随后客户听到，从理论上讲，CRC检查可能无法100％检测到所有错误.

是真的. 您如何说服他相信您的系统可以实现无错传输？如果在数据包传输期间发生错误，但是接收端无法检测到错误，则将其计为数据包级错误. 客户使用此实验中描述的渠道. 客户的通信系统每天使用50％的时间，也就是说，每天只有一半的时间在传输数据. 根据您对CRC32错误检测功能的了解，发生一个包错误代码事件，需要多少年？从Internet或其他参考书中查找相关材料，并查看CRC32是否充分考虑了线路错误的概率模型以及实际的检查能力. 您的计算过于保守吗？实际表现是否夸张？如果您对客户的回答对分组层的错误率不满意，那么您需要采取什么措施来减少分组层错误事件的可能性，这些措施的成本是多少？答: CRC验证能力确实有限，但是实际通道的误码率通常不高于此实验. 因此，总共超过20小时的测试性能非常稳定，因此CRC验证能力也是可见的. 在这种信道误码率的情况下，它是足够有效的. 另一方面，如果CRC校验错误导致向网络层传输错误数据，则网络层也可以使用校验方法进行错误检测和重传，从而进一步保证传输的正确性. 编程问题问: 第8.10节中提出的协议软件的跟踪功能的意义是什么？您的程序是否实现此功能？程序库中用于获取时间坐标的函数get_ms（）是C标准库中的函数. 您可以自己实现返回功能吗？我已经在“ C编程”课程中研究了printf函数，但是教科书可能没有解释如何设计类似返回的函数.

printf样式函数的特征在于parameters确定参数的数量，类似于标准库函数迓24/27计算机网络实验和报告包含fprintf，sprintf，scanf等. 调试程序后，该库提供了log_printf和lprintf函数（请参见8.3），用于同步输出日志文件和屏幕窗口. 这些函数不是标准的C语言库函数，并且调用样式与printf不同. 如果本实验提供的库包含两个函数，您可以自己实现它吗？建议从Internet检索相关信息，或直接检查Linux源代码以查看如何实现printf样式的功能. 答: 跟踪功能在此实验中起着至关重要的作用，因为它使我知道此时此刻正在发生什么. 无论是调试还是监视其他事物，这都非常重要. 我可以自己实现类似的功能. 关于软件测试的问题问: 验证完成的程序在各种情况下能否正常运行是软件测试的主要目的. 表3列出了七个测试方案. 设计多个测试方案的目的是什么？分析每个测试方案. 协议软件中每种方案的主要目标是什么？假设您的协议软件出了什么问题，测试将失败？您认为这些测试发现了哪些问题？这些测试解决方案和验证协议正确性的方法由讲师提供. 如果您自己完成整个协议的设计和测试，将使用哪些方法来验证程序是否正常运行？针对此实验的特定问题，您能否提出更有效的软件测试解决方案？该实验提供的程序库足够多，以及如何为协议的开发提供更方便的支持，这与整个软件开发过程中不同模块之间的功能划分有关. 提供您的建议.

A: 由于网络环境是多种多样的，并且网络协议的功能可能不是单一的，因此只能通过多种测试方案来不可靠地测量协议的性能. 如果参数（窗口大小，ACK_TIME，DATA_TIME）设置合理，我在本实验中编写的协议可以长时间稳定运行，而不会崩溃，但是我也发现如果参数设置不合理（例如窗口也是如此），等等，可能会导致诸如物理层缓冲区溢出之类的问题，从而导致系统崩溃. 不同测试解决方案的目的是: 数据链路au（bu）: 测试无错误代码的双工传输的线路利用率，并可以测量双工模式下协议的实际最大线路利​​用率. 数据链路a（b）: 在特定误码率（1e-5）下测试双工传输的线路利用率，并可以在具有特定误码率利用率的信道上以双工工作模式测量协议的实际线路. datalink afu（bfu）: 测试在无错误通道上以泛洪模式工作的线路的利用率. datalink af（bf）: 测试在错误代码为（1e-4）的信道上以淹没模式工作的线路的利用率. 25/27计算机网络实验和报告数据链接af（bf）– 1e-4: 测试在错误通道（1e-5）上以淹没模式工作的线路的利用率. 对等协议实体之间的流控制问: 教科书中多次提到“流控制”问题. 这个问题确实很重要.

在此实验中设计的程序中，也考虑了上下软件实体之间的数据流控制. 您是否认为您设计的滑动窗口协议软件解决了两个站点的数据链路层对等实体之间的流控制问题？如果已经解决，如何解决？如果不是，则需要更改协议的哪些方面？答: 只能静态解决流量控制问题，不能根据网络的具体情况进行状态调整. 与标准协议的比较问: 如果实际上有两个站相距5,000公里，它们将使用您设计的通过卫星信道进行通信的协议. 需要解决什么问题？实验方案和实际方案之间有什么区别？您认为需要添加哪些功能？答: 对于相距很远的卫星通信，要考虑的因素主要是信道因素，包括信道的连通性. 卫星有可能偏离通信范围吗？通道的稳定性和波动率的误码率例如，延迟，延迟等，取决于这些因素，您可能需要考虑状态调整协议中的参数（包括ACK_TIME，DATA_TIME等）. 八，实验总结和经验本实验的非调试工作时间约为6到7个小时，但没有花费在测试（不报告）上的时间. 相同参数（窗口大小，ACK_TIME，DATA_TIME）的设置会在实际条件下影响协议的工作条件.

程序本身遇到的问题很多. 如上所述，主要问题是参数选择问题. 至于协议，模板已由advance预先给出，因此没有太大问题. 打开仓库没有遇到任何问题. 通过该实验，我意识到调试网络协议（或升级为网络程序的许可证）不会测试不在本地运行的软件. 有一个很大的不同. 它们更难调试且更难测试. 如果不调试，则必须将其放在网络环境中. 数据流的范围更广，并且与网络环境的复杂性无关. 26/27

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-161874-2.html