课程设计报告滑动窗口协议仿真
滑动窗口的仿真协议
滑动窗口的仿真协议协议名称：滑动窗口仿真协议1. 引言本协议旨在定义滑动窗口的仿真协议，以模拟数据传输过程中的滑动窗口机制。
滑动窗口是一种流行的数据传输方式，通过动态调整发送方和接收方之间的窗口大小，实现高效的数据传输。
本协议将详细描述滑动窗口的仿真过程、相关参数以及数据传输的规则。
2. 术语定义在本协议中，以下术语将被定义如下：- 发送方（Sender）：负责将数据分片发送给接收方的实体。
- 接收方（Receiver）：负责接收发送方发送的数据分片的实体。
- 窗口（Window）：发送方和接收方之间的数据传输窗口，用于控制发送和接收的数据量。
- 序列号（Sequence Number）：用于标识数据分片的唯一编号。
- 确认号（Acknowledgement Number）：用于确认接收到的数据分片的序列号。
- 超时计时器（Timeout Timer）：用于计算数据分片的超时时间。
3. 协议流程本协议的流程如下：1) 发送方将数据分片按照滑动窗口大小进行划分，并逐个发送。
2) 接收方接收到数据分片后，将其存储在接收缓冲区中。
3) 接收方通过确认号向发送方发送确认信息，确认已接收到的数据分片。
4) 发送方根据接收到的确认信息，动态调整窗口大小。
5) 发送方根据窗口大小和确认信息，决定是否发送新的数据分片。
6) 发送方设置超时计时器，若在超时时间内未收到确认信息，则重传对应的数据分片。
7) 接收方根据序列号对接收到的数据分片进行排序，并将有序的数据传递给上层应用。
4. 协议参数本协议涉及的参数如下：- 窗口大小（Window Size）：指发送方和接收方之间的数据传输窗口的大小。
窗口大小决定了同时发送和接收的数据分片数量。
- 序列号范围（Sequence Number Range）：指数据分片的序列号范围，用于唯一标识每个数据分片。
- 超时时间（Timeout）：指发送方等待确认信息的超时时间。
若超过超时时间仍未收到确认信息，则进行重传操作。
滑动窗口的仿真协议
滑动窗口的仿真协议协议名称：滑动窗口的仿真协议一、引言本协议旨在定义滑动窗口的仿真协议，用于模拟网络通信中滑动窗口协议的行为和性能。
滑动窗口协议是一种流行的数据传输协议，用于实现可靠的数据传输。
通过仿真滑动窗口协议，我们可以评估协议的性能，并进行性能优化。
二、背景滑动窗口协议是一种基于窗口机制的数据传输协议，常用于计算机网络中。
其核心思想是发送方和接收方通过维护一个窗口来实现流量控制和错误恢复。
滑动窗口协议具有高效、可靠和灵活等特点，因此被广泛应用于各种网络通信场景。
三、目的本协议的目的是定义滑动窗口的仿真协议，用于模拟滑动窗口协议的行为和性能。
通过仿真，我们可以评估滑动窗口协议在不同条件下的性能表现，包括吞吐量、延迟、丢包率等指标。
同时，我们可以通过仿真结果来优化滑动窗口协议的设计和参数配置。
四、协议内容1. 协议参与方：- 发送方：模拟数据发送方，负责发送数据包并维护滑动窗口。
- 接收方：模拟数据接收方，负责接收数据包并发送确认信息。
- 网络模拟器：模拟网络环境，包括延迟、丢包等特性。
2. 协议流程：a. 发送方将数据包划分为多个固定大小的数据块，并按序号进行编号。
b. 发送方维护一个发送窗口，窗口大小为W，初始时窗口为空。
c. 发送方按顺序发送窗口内的数据包，同时启动定时器。
d. 接收方接收数据包，并发送确认信息。
e. 发送方收到确认信息后，将对应的数据包从发送窗口中移除，并滑动窗口。
f. 若发送方未收到确认信息，定时器超时，发送方重新发送窗口内的数据包。
g. 若接收方未收到期望的数据包，发送方重新发送该数据包。
h. 协议持续运行，直到所有数据包都被正确接收或达到最大重传次数。
3. 参数配置：- 数据包大小：定义数据包的大小，影响传输效率和网络利用率。
- 窗口大小：定义发送窗口的大小，影响流量控制和吞吐量。
- 超时时间：定义定时器的超时时间，影响错误恢复和延迟。
- 最大重传次数：定义最大重传次数，用于控制错误恢复的次数。
滑动窗口的仿真协议
滑动窗口的仿真协议协议名称：滑动窗口的仿真协议1. 引言本协议旨在定义滑动窗口的仿真协议，以实现数据传输的可靠性和效率。
该协议适用于需要传输大量数据的通信系统，特别是在网络通信中应用广泛。
本协议的目标是确保数据的可靠传输，同时最大化数据传输的效率。
2. 术语和定义在本协议中，以下术语和定义适用：- 发送方（Sender）：负责将数据发送给接收方的实体。
- 接收方（Receiver）：负责接收发送方传输的数据的实体。
- 数据帧（Data Frame）：将数据分割为固定大小的块进行传输的单元。
- 窗口（Window）：发送方和接收方之间的数据传输缓冲区。
- 序列号（Sequence Number）：用于标识数据帧在发送方和接收方之间的顺序。
- 确认号（Acknowledgement Number）：用于确认接收方已成功接收到的数据帧的序列号。
3. 协议流程3.1 发送方流程发送方执行以下步骤来实现滑动窗口的仿真协议：步骤1：初始化发送窗口的大小和初始序列号。
步骤2：将数据分割为适当大小的数据帧。
步骤3：将数据帧按照顺序发送给接收方。
步骤4：等待接收方的确认。
步骤5：接收到确认后，滑动发送窗口，更新序列号，并继续发送下一个数据帧。
步骤6：如果在一定时间内未收到确认，则重新发送未确认的数据帧。
3.2 接收方流程接收方执行以下步骤来实现滑动窗口的仿真协议：步骤1：初始化接收窗口的大小和初始序列号。
步骤2：等待发送方发送数据帧。
步骤3：接收到数据帧后，检查序列号是否与期望的序列号匹配。
步骤4：如果匹配，则发送确认给发送方，并将数据帧交付给上层应用。
步骤5：如果不匹配，则丢弃数据帧，并发送确认给发送方，确认接收到的最后一个正确的数据帧。
步骤6：滑动接收窗口，更新序列号，准备接收下一个数据帧。
4. 错误处理4.1 超时重传如果发送方在一定时间内未收到接收方的确认，则发送方将重新发送未确认的数据帧。
4.2 丢失数据帧如果接收方未收到发送方发送的数据帧，则接收方将发送一个确认，确认接收到的最后一个正确的数据帧，并要求发送方重新发送丢失的数据帧。
计算机网络--滑动窗口实验报告
计算机网络--滑动窗口实验报告计算机网络滑动窗口协议实验报告目录一、实验内容和实验环境描述（2）1.实验内容（2）2.实验目的（2）3.实验环境（2）二、协议设计（3）三、软件设计（4）Part A 选择重传协议1.数据结构（4）2.模块结构（6）3.算法流程（7）Part B gobackn协议 1.数据结构（8）2.模块结构（9）3.算法流程（10）四、实验结果分析（11）五、探究问题（13）六、实验总结与心得体会（14）一、实验内容和实验环境描述1.实验内容利用所学数据链路层原理，自己设计一个滑动窗口协议，在仿真环境下编程实现有噪音信道环境下两站点之间无差错双工通信。
信道模型为8000bps全双工卫星信道，信道传播时延270毫秒，信道误码率为10?5，信道提供字节流传输服务，网络层分组长度固定为 256 字节。
2.实验目的通过该实验，进一步巩固和深刻理解数据链路层误码检测的CRC校验技术，以及滑动窗口的工作机理。
滑动窗口机制的两个主要目的：（1）实现有噪音信道环境下的无差错传输；（2）充分利用传输信道的带宽。
在程序能够稳定运行并成功实现第一个目标之后，运行程序并检查在信道没有误码和存在误码两种情况下的信道利用率。
为实现第二个目标，提高滑动窗口协议信道利用率，需要根据信道实际情况合理地为协议配置工作参数，包括滑动窗口的大小和重传定时器时限以及 ACK 搭载定时器的时限。
3.实验环境Windows10环境PC机Microsoft Visual Studio 2017集成开发环境二、协议设计本次试验主要设计数据链路层,实验中分别设计了gobackn协议与选择重传协议。
主要涉及到的层次结构是物理层、数据链路层、网络层。
物理层：为数据链路层提供的服务为8000bps，270ms传播延时，10?5误码率的字节流传输通道。
数据链路层利用接口函数send_frame()和 recv_frame()从物理层发送和接收一帧。
滑动窗口的仿真合约协议
计算机网络课程设计书计算机网络课程设计说明书（封面）学院名称：计算机与信息工程学院班级名称：网络工程一班学生姓名：学号：201321题目：滑动窗口协议仿真指导教师姓名：邵雪梅起止日期：2015.6.23－2015.6.29第一部分：正文部分一，选题背景早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。
由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。
在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这就造成数据的丢失。
因此就有了滑动窗口机制来解决这些问题。
早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认才发下一个帧，这样对信道的利用率太低了。
因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送ack确认，而是收到几个帧后，对按序到达的最后一个帧发送ack确认。
同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack对传输效率的影响。
但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第3个帧丢失了。
这时接收方只能对前2个帧发出确认。
发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。
为了解决这个问题，又提出了选择重传协议。
当接收方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们，存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。
一旦收到重传来的帧后，就可以将存于缓冲区中的其余帧一并按正确的顺序递交给主机。
本文主要介绍如何根据滑动窗口协议的原理，在Visual C++的平台上设计一个滑动窗口协议模拟程序，并最终使该程序得以实现。
本次程序设计分两部分：第一部分是发送方，第二部分是接收方。
通过发送方和接收方之间的数据帧传输模拟，学习滑动窗口协议控制流量的原理和方法，以及滑动窗口协议的工作机制。
二、设计理念2.1滑动窗口协议工作原理TCP滑动窗口用来暂存两台计算机间要传送的数据分组。
滑动窗口协议实验报告
滑动窗口协议实验报告1. 引言滑动窗口协议是计算机网络中用于实现可靠数据传输的一种协议。
其核心思想是使用一个窗口来管理发送方和接收方之间的数据传输进程，通过滑动窗口的机制来实现流量控制和错误恢复。
本实验旨在通过编写滑动窗口协议的模拟程序，深入理解该协议的工作原理及其在数据传输中的应用。
2. 实验环境本次实验采用C++语言进行编程，并在Windows操作系统下进行测试。
3. 实验过程3.1 窗口大小的确定首先，我们需要确定滑动窗口的大小。
在实际应用中，窗口大小需要根据网络状况来调整，以保证传输效率。
本次实验中，我们设置窗口大小为5。
3.2 发送方逻辑实现发送方负责将数据分割为若干个数据包，并发送给接收方。
发送方需要维护发送窗口的起始位置和结束位置，在每次发送数据包后，将发送窗口向前滑动一格。
如果接收窗口收到接收方的确认信息，发送方将收到确认的数据包从发送窗口中移除，并将窗口向前滑动一格。
3.3 接收方逻辑实现接收方需要维护接收窗口的起始位置和结束位置。
当接收窗口收到数据包时，接收方首先检查数据包的顺序是否正确，如果顺序正确，则将数据包保存并发送确认信息给发送方。
接收方随后将接收窗口向前滑动一格，等待下一个数据包的到来。
3.4 测试与验证在实验过程中，我们通过模拟网络传输的延迟、丢包等情况来验证滑动窗口协议的可靠性。
通过调整滑动窗口的大小以及模拟网络传输的不同情况，我们可以观察到滑动窗口协议在不同场景下的性能表现。
4. 实验结果分析通过实验，我们观察到滑动窗口协议在正常网络传输情况下，能够实现高效的数据传输。
当网络传输出现延迟或丢包时，滑动窗口协议能够通过重传机制和流量控制策略，确保数据的可靠传输。
在窗口大小适当的情况下，滑动窗口协议能够最大化利用网络带宽，提高数据传输的效率。
5. 实验总结本次实验通过编写模拟程序，深入理解了滑动窗口协议的工作原理及其在数据传输中的应用。
滑动窗口协议通过窗口的滑动机制，实现了对数据传输过程的控制和管理，从而保证了数据的可靠性和传输效率。
课程设计报告-滑动窗口协议仿真
滁州学院课程设计报告课程名称：计算机网络设计题目：滑动窗口协议仿真系别：计算机与信息工程学院专业：计算机科学与技术组别：第五组起止日期: 2011年11月24日~2011年12月7日****:***计算机与信息工程学院二○一一年制课程设计任务书一. 引言二. 基本原理2.1 窗口机制2.2 1bit滑动窗口协议2.3 后退N协议2.4 选择重传协议2.5 流量控制三. 需求分析3.1 课程设计题目3.2 开发环境3.3 运行环境3.4 课程设计任务及要求3.5 界面要求3.6 网络接口要求四. 详细设计4.1 结构体的定义4.2 发送方的主要函数4.3 接受方的主要函数五.源代码5.1 发送方的主要代码5.2 接收方的主要代码六. 调试与操作说明致谢[参考文献]课程设计的主要内容1.引言早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。
由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。
在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这就造成数据的丢失。
因此就有了滑动窗口机制来解决这些问题。
早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认才发下一个帧，这样对信道的利用率太低了。
因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送ack确认，而是收到几个帧后，对按序到达的最后一个帧发送ack确认。
同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack对传输效率的影响。
但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第3个帧丢失了。
这时接收方只能对前2个帧发出确认。
发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。
为了解决这个问题，又提出了选择重传协议。
当接收方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们，存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。
滑动窗口协议模拟
实验8滑动窗口协议模拟一、实验目的1.模拟实现滑窗协议在数据链路层上的数据传输过程，加深对滑窗协议的理解2.掌握滑动窗口协议基本原理与基本算法；二、要求：1.掌握滑动窗口协议的概念、原理与基本算法；2.实现“选择性重传策略或连续自动重传策略（后退N帧）”的滑动窗口协议模拟程序；3.了解传输层和链路层滑动窗口协议的区别与联系及TCP中滑动窗口协议的实现原理。
三、实验原理滑窗协议工作原理由于停等协议要为每一个帧进行确认后才继续发送下一个帧，大大降低了信道利用率，因此又提出来回退N帧的滑窗协议。
回退N帧协议中，发送方在发送完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。
由于减少了等待时间，必然提高通信的吞吐量和信道利用率。
回退N帧的滑窗协议（GO-DACK-N）基本原理是，当接收方检测出错的信息帧后，丢弃出错帧后的所有信息帧，而不管这些帧是否正确。
待发送方收到对出错帧的否定应答（NAK）时，将重发从出错后的所有数据帧；若应答帧出错，则超时重发。
因此，发送方在每发完一个数据帧时都要设置超时计时器。
只要在所设置的计时器超时而仍未收到确认帧，就要重发相应的数据帧，若等不到1号帧的确认应答而重发1号数据帧时，虽然发送方已经发送完3号帧，但仍必须将1号帧及其以后的各帧全部进行重传。
因此，后退N帧协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传，这种做法又使传送率降低。
四、实验要求1.Windows XP环境下运行，程序在1~2台PC上运行。
2.具体实现的协议可以采用回退N帧技术或者选择性重发技术的协议。
3.采用.NET平台中的C#、C++或其他编程语言实现。
五、实验内容模拟滑窗协议的实现过程为;（1)程序客户端线程发送连接请求。
(2) 服务器连接并返回连接信息。
（3) 客户端发送数据帧（窗口大小自行设定）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
课程设计报告滑动窗口协议仿真公司内部档案编码：[OPPTR-OPPT28-OPPTL98-OPPNN08]滁州学院课程设计报告课程名称：计算机网络设计题目：滑动窗口协议仿真系别：计算机与信息工程学院专业：计算机科学与技术组别：第五组起止日期: 2011年11月24日~2011年12月7日指导教师:赵国柱计算机与信息工程学院二○一一年制课程设计任务书一. 引言二. 基本原理窗口机制1bit滑动窗口协议后退N协议选择重传协议流量控制三. 需求分析课程设计题目开发环境运行环境课程设计任务及要求界面要求网络接口要求四. 详细设计结构体的定义发送方的主要函数接受方的主要函数五. 源代码发送方的主要代码接收方的主要代码六. 调试与操作说明致谢[参考文献]课程设计的主要内容1.引言早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。
由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。
在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这就造成数据的丢失。
因此就有了滑动窗口机制来解决这些问题。
早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认才发下一个帧，这样对信道的利用率太低了。
因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送ack 确认，而是收到几个帧后，对按序到达的最后一个帧发送ack确认。
同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack对传输效率的影响。
但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第3个帧丢失了。
这时接收方只能对前2个帧发出确认。
发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。
为了解决这个问题，又提出了选择重传协议。
当接收方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们，存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。
一旦收到重传来的帧后，就可以将存于缓冲区中的其余帧一并按正确的顺序递交给主机。
2.基本原理窗口机制滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。
发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。
不同的滑动窗口协议窗口大小一般不同。
发送方窗口内的序号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。
接受方为其窗口内的每一个序号保留了一个缓冲区。
与每个缓冲区相关联的还有一位，用来指明该缓冲区是满的还是空的。
若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。
1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退N协议：发送窗口>1，接收窗口=1；选择重传协议：发送窗口>1,接收窗口>1。
1bit滑动窗口协议当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。
该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。
由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。
由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。
其发送方和接收方运行的流程图如图所示。
后退N协议由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。
后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。
且发送方在每发送完一个数据帧时都要设置超时定时器。
只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。
如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。
由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。
此协议中的发送窗口的大小为k，接收窗口仍是1。
选择重传协议在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。
另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。
一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。
这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。
显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。
流量控制TCP的特点之一是提供体积可变的滑动窗口机制，支持端到端的流量控制。
TCP的窗口以字节为单位进行调整，以适应接收方的处理能力。
处理过程如下：（1）TCP连接阶段，双方协商窗口尺寸，同时接收方预留数据缓存区；（2）发送方根据协商的结果，发送符合窗口尺寸的数据字节流，并等待对方的确认；（3）发送方根据确认信息，改变窗口的尺寸，增加或者减少发送未得到确认的字节流中的字节数。
调整过程包括：如果出现发送拥塞，发送窗口缩小为原来的一半，同时将超时重传的时间间隔扩大一倍。
（4）滑动窗口机制为端到端设备间的数据传输提供了可靠的流量控制机制。
然而，它只能在源端设备和目的端设备起作用，当网络中间设备（例如路由器等）发生拥塞时，滑动窗口机制将不起作用。
3.需求分析课程设计题目：滑动窗口协议仿真开发环境：Visual C++运行环境：Windows 操作系统课程设计任务及要求：（1）程序按照滑动窗口协议实现端对端的数据传送。
包括协议的各种策略，如包丢失、停等应答、超时等都应有所仿真实现。
（2）显示数据传送过程中的各项具体数据。
双方帧的个数变化，帧序号，发送和接受速度，暂停或重传提示等。
界面要求：此次课程设计要求的所有功能应可视，我们组主要是用VC++编写的，运行在DOS环境下，观察发送方（sender）发送数据包到接收方（receive）时。
界面应显示出双方帧个数的变化，帧序号，发送和接受速度，暂停或重传提示等，界面中必须动态显示数据帧的发送和接受情况，包括在相应的窗口详细显示相应的ACK和其他收发数据帧后发出的消息，以表明模拟协议的正确运作过程。
在各种情况下，接受方和发送方窗口应实时显示帧的发送和接受情况，包括序号，时间戳，内容等。
以及窗口的填充和清空情况。
网络接口要求：两台机器或是一台机器中两个独立的线程模拟发送方与接受方，接收数据的端口初始应为监听状态。
发送方向接受方发起连接，成功后开始发送数据。
4.概要设计结构体定义如下：typedef enum {data = 1,ack,nak,tout} frame_kind; 代码发送方的主要代码：void InitLine(LinkQueue *q){q->front = q->rear = NULL;}int QueueEmpty(LinkQueue *q){return q->front == NULL && q->rear == NULL; }frame QueueFront(LinkQueue *q){if (QueueEmpty(q)){printf("队列为空！\n");Sleep(SLEEPMS);exit(0);}return q->front->head_data;}int QueueLen(LinkQueue *q){if (QueueEmpty(q)){return 0;}int num = 0;Framenode *p = q->front;while(p != NULL){num++;p = p->next;}return num;}void GetFrameFromHost(LinkQueue *q) {if(QueueLen(q) >= MAXPOOL){return;}Framenode *p=(Framenode *)malloc(sizeof(Framenode));srand((unsigned)time(NULL));p-> = rand() % MAX_LENGTH; . \n");Begin:WORD wVersionRequested;WSADATA wsaData; 按q退出，其他键继续\n");int kbc = getch();if(kbc == 'q' || kbc == 'Q')break;}}printf("按任意键退出！\n");while (!kbhit()) {};Sleep(SLEEPMS);printf("谢谢使用！\n");WSACleanup();closesocket(socketClient);Sleep(SLEEPMS);}DWORD WINAPI ReceiveFun(LPVOID pArg){EnterCriticalSection(&gCS);{}else{curw = DeLine(&QueueQ, &packetreceive, curw); 试与操作说明用户打开接收方程序时会自动等待发送方，打开发送方程序时会自动尝试连接接收方程序。
当发送方程序和接收方程序都打开时，发送程序将连接接收方程序，连接成功时会有提示信息。
在发送方按任意键开始模拟，发送与接受是自动进行，出现各种情况（帧丢失、帧出错、ack丢失等）的概率都是20%，程序执行20秒后会提示是否继续执行。
如图：1，2是正常情况：发送方发送数据帧->接受方收到数据帧，经检验该数据帧正确，发送确认帧->发送方收到确认帧，删除已收到确认的数据帧。
3，4是数据帧丢失：发送方发送数据帧->接受方未收到数据帧，没有任何动作->发送方超时重传该数据帧。
5，6是数据帧出错：发送方发送数据帧->接收方收到数据帧，经检验该数据帧出错，发送否认帧->接受方收到否认帧，重传该数据帧。