滑动窗口的仿真协议书范本
滑动窗口的仿真协议
滑动窗口的仿真协议协议名称：滑动窗口仿真协议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.1 甲方同意向乙方提供其拥有的仿真技术及相关产品，乙方同意购买并使用甲方的仿真技术及相关产品。
1.2 乙方同意在自身业务范围内积极推广甲方提供的仿真技术及相关产品，并向甲方提供市场反馈和客户需求信息。
1.3 甲乙双方共同开展技术交流和培训活动，提高双方技术水平和业务能力。
二、合作区域和期限2.1 本合作协议所涉及的合作区域为全国。
2.2 本合作协议的有效期为____年，自双方签字之日起计算。
三、合作条件3.1 甲方应保证其提供的仿真技术及相关产品符合国家法律法规、行业标准和乙方要求。
3.2 乙方应按照双方约定的价格购买甲方提供的仿真技术及相关产品，并按照约定支付货款。
四、合作权益4.1 甲乙双方应共同维护对方的合法权益，不得以任何形式损害对方的声誉和利益。
4.2 甲方应在合作协议有效期内，向乙方提供技术支持和售后服务。
4.3 乙方应在合作协议有效期内，积极推广甲方的仿真技术及相关产品，并按照约定支付货款。
五、违约责任5.1 甲乙双方如违反本合作协议的约定，应承担违约责任，向守约方支付违约金，并赔偿因此给对方造成的损失。
5.2 若甲方未能按照约定提供仿真技术及相关产品，乙方有权解除本合作协议，并要求甲方支付违约金。
六、争议解决6.1 甲乙双方在履行本合作协议过程中发生的争议，应首先通过友好协商解决；协商不成的，可以向有管辖权的人民法院起诉。
仿真系统技术协议书范本
仿真系统技术协议书范本甲方（委托方）：____________________乙方（受托方）：____________________鉴于甲方需要对特定仿真系统进行开发和测试，乙方具备相应的技术能力和经验，双方本着平等自愿、诚实信用的原则，就仿真系统开发事宜达成如下技术协议：一、项目概述1. 项目名称：_______________________2. 项目目的：_______________________3. 仿真系统功能：_________________4. 技术要求：_____________________二、技术规格和性能指标1. 仿真系统应满足以下性能指标：- 精度：_______________________- 稳定性：_______________________- 响应时间：_____________________2. 技术规格应包括但不限于：- 硬件配置：_____________________- 软件架构：_____________________- 数据处理能力：_________________三、开发周期和交付物1. 开发周期：从合同签订之日起至_________年____月____日。
2. 交付物包括：- 仿真系统软件- 用户手册- 技术文档- 测试报告四、质量保证和技术支持1. 乙方应保证仿真系统的开发质量，符合甲方的技术要求。
2. 乙方提供_________个月的免费技术支持和维护服务。
五、知识产权1. 仿真系统的知识产权归乙方所有，甲方拥有使用权。
2. 甲方不得将仿真系统用于任何商业目的，未经乙方书面同意。
六、保密条款1. 双方应对本协议内容及在合作过程中知悉的对方商业秘密保密。
2. 保密期限为自本协议签订之日起至项目结束后五年。
七、违约责任1. 如一方违反本协议条款，应承担违约责任，并赔偿对方因此遭受的损失。
八、争议解决1. 双方因履行本协议发生争议，应首先通过友好协商解决；协商不成时，提交甲方所在地人民法院诉讼解决。
滑动窗协议书范本
滑动窗协议书范本甲方（发送方）：_____________________乙方（接收方）：_____________________鉴于甲方需要通过电子方式向乙方传输数据，为了保证数据传输的可靠性和有效性，双方本着平等互利的原则，经协商一致，就采用滑动窗协议进行数据传输的相关事宜达成如下协议：1. 定义1.1 滑动窗协议：一种用于计算机网络中传输数据的流量控制机制，允许发送方在等待接收方确认的情况下发送一定数量的未经确认的数据。
2. 协议参数2.1 窗口大小：甲方在未收到乙方确认的情况下，可以连续发送的数据包数量。
2.2 数据包编号：每个数据包的唯一标识，用于乙方确认已接收的数据包。
3. 数据传输流程3.1 发送方在每个数据包中包含一个序列号，用于乙方识别和排序。
3.2 接收方在接收到数据包后，应发送确认信息，告知发送方已成功接收的数据包编号。
3.3 发送方根据接收方的确认信息，决定是否发送新的数据包或重新发送未被确认的数据包。
4. 窗口管理4.1 甲方应根据乙方的接收能力和网络状况合理设置窗口大小。
4.2 乙方应即时向甲方反馈接收状态，以便甲方调整窗口大小。
5. 错误处理5.1 如乙方发现数据包丢失或错误，应立即通知甲方，并提供丢失或错误的数据包编号。
5.2 甲方在收到乙方的错误通知后，应重新发送指定编号的数据包。
6. 数据完整性6.1 甲方保证所发送的数据包内容的完整性和正确性。
6.2 乙方在接收数据包后，应进行完整性校验，确保数据未被篡改。
7. 安全保密7.1 双方应采取必要的安全措施，保护传输过程中的数据不被未授权访问。
7.2 双方应对传输过程中的数据保密，未经对方书面同意，不得向第三方披露。
8. 协议变更8.1 任何一方需变更协议内容，应提前____天书面通知对方，并经双方协商一致。
9. 违约责任9.1 如一方违反本协议约定，应承担相应的违约责任，并赔偿对方因此遭受的损失。
10. 争议解决10.1 本协议在执行过程中发生争议，双方应首先通过协商解决；协商不成的，可提交甲方所在地人民法院诉讼解决。
仿真模拟技术协议书范本
仿真模拟技术协议书范本甲方（委托方）：[甲方全称]乙方（受托方）：[乙方全称]鉴于甲方需要进行仿真模拟技术的应用，乙方具有相应的技术能力和服务经验，双方本着平等互利的原则，经友好协商，就仿真模拟技术服务达成如下协议：一、服务内容1. 乙方根据甲方的需求，提供仿真模拟技术服务，包括但不限于仿真系统的设计、开发、调试和优化。
2. 乙方应保证所提供的仿真模拟技术服务满足甲方的技术要求和性能指标。
3. 乙方应负责仿真模拟系统的安装、调试和培训工作，确保甲方能够独立操作和维护系统。
二、技术要求1. 仿真模拟系统应具备高度的逼真性，能够模拟实际工作环境中的各种情况。
2. 系统应具备良好的稳定性和可靠性，能够长时间稳定运行。
3. 系统应易于操作，界面友好，便于甲方人员快速掌握。
三、服务期限1. 本协议自双方签字盖章之日起生效，有效期至[具体日期]。
2. 在服务期限内，乙方应按照甲方的需求，提供持续的技术支持和服务。
四、费用及支付方式1. 甲方应向乙方支付仿真模拟技术服务费用，具体金额为[金额]。
2. 支付方式为[支付方式]，甲方应在合同签订后[时间]内支付首期费用，余款在服务完成后[时间]内支付。
五、保密条款1. 双方应对在合作过程中知悉的对方商业秘密和技术秘密负有保密义务。
2. 未经对方书面同意，任何一方不得向第三方披露、泄露或允许他人使用对方的商业秘密和技术秘密。
六、违约责任1. 如一方违反本协议约定，应承担违约责任，并赔偿对方因此遭受的损失。
2. 因不可抗力导致不能履行或延迟履行本协议的，双方应协商解决，不视为违约。
七、争议解决双方在履行本协议过程中发生争议，应首先通过友好协商解决；协商不成时，任何一方均可向甲方所在地人民法院提起诉讼。
八、其他1. 本协议未尽事宜，双方可另行签订补充协议。
2. 本协议一式两份，甲乙双方各执一份，具有同等法律效力。
甲方代表（签字）：___________乙方代表（签字）：___________签订日期：____年__月__日。
滑动窗口的仿真合约协议
计算机网络课程设计书计算机网络课程设计说明书（封面）学院名称：计算机与信息工程学院班级名称：网络工程一班学生姓名：学号：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需求分析 (3)1.1 问题重述 (3)2概要设计 (4)2.1 原理概述 (4)2.2 主要问题 (4)2.2 数据结构 (5)2.3 算法分析 (6)2.4 行为模型 (9)2.5 端口设置 (10)3详细设计 (10)3.1 参数说明 (10)3.2 主要函数说明 (11)4测试报告 (16)4.1 正常发送模式测试 (16)4.2 错序发送模式测试 (17)4.3 信道出错测试 (18)4.4 信道丢帧测试 (19)4.5 信道丢失确认帧测试 (20)5简明用户手册 (21)6 项目评价 (22)6.1 项目总结 (22)6.2 心得体会 (23)6.3 有待改进的地方 (23)附录一：参考书目及其他 (24)1. 需求分析实验目的：加深对滑动窗口协议的理解实验任务：实现对于滑动窗口协议的模拟实验环境：1~2台PC机操作系统：Windows XP开发环境：Microsoft Visual C++ 6.0 ，可以使用MFC类库1.1问题重述界面要求：项目要求的所有功能应可视，要有简单的界面。
由一台PC（或线程）向另一台PC（或线程）发送数据包时，界面应显示出双方帧个数的变化，帧序号，发送和接受速度，暂停或重传提示等，界面中必须动态显示数据帧的发送和接受情况，包括在相应的窗口详细显示相应的ACK和其他收发数据帧后发出的消息，以表明模拟协议的正确运作过程。
在各种情况下，接受方和发送方窗口应实时显示帧的发送和接受情况，包括序号，时间戳，内容等。
以及窗口的填充和清空情况。
网络接口要求：两台机器或是一台机器中两个独立的线程模拟发送方与接受方，接收数据的端口初始应为监听状态。
发送方向接受方发起连接，成功后开始发送数据。
接受方要求：接受方应由固定大小的滑动窗口，并对收到信息缓存。
当发送方速度过快或帧丢失（超时），接受方应发送消息，要求暂停或是重传（停---等协议）。
滑动窗口的仿真协议
滑动窗口的仿真协议协议名称：滑动窗口的仿真协议1. 引言本协议旨在描述滑动窗口的仿真过程，并规定了参与方的角色、通信流程、数据传输机制等内容，以确保数据的可靠传输和系统的稳定运行。
2. 参与方本协议涉及以下参与方：- 发送方（Sender）：负责将数据分割为适当大小的数据包，并通过滑动窗口机制发送数据。
- 接收方（Receiver）：接收发送方发送的数据包，并确认接收到的数据包。
- 网络（Network）：承载发送方和接收方之间的数据传输。
3. 通信流程3.1 发送方初始化发送方在开始数据传输前，需要进行初始化操作。
具体流程如下：- 发送方设置滑动窗口的大小（窗口大小）和初始序列号（初始序号）。
- 发送方将待发送的数据分割为适当大小的数据包，并为每个数据包分配一个序列号。
- 发送方将窗口内的数据包发送给接收方，并启动计时器。
3.2 数据传输发送方通过滑动窗口机制将数据发送给接收方。
具体流程如下：- 发送方发送窗口内的数据包给接收方。
- 接收方接收到数据包后，进行校验和验证，如果数据包有误，则丢弃该数据包。
- 接收方发送确认（ACK）给发送方，确认接收到的数据包。
- 发送方收到确认后，将确认的数据包从窗口内移除，并向前滑动窗口。
- 如果发送方在一定时间内没有收到确认，认为该数据包丢失，将重新发送该数据包。
3.3 窗口滑动窗口滑动是滑动窗口机制的核心步骤。
具体流程如下：- 当发送方收到接收方的确认时，发送方将窗口内的数据包移除，并将窗口向前滑动。
- 发送方将新的数据包发送给接收方，并启动计时器。
4. 数据传输机制4.1 停等协议发送方发送一个数据包后，会等待接收方的确认，直到收到确认后才发送下一个数据包。
如果发送方在一定时间内没有收到确认，将重新发送该数据包。
4.2 滑动窗口滑动窗口机制允许发送方在等待接收方确认的同时继续发送新的数据包。
发送方维护一个窗口，窗口内的数据包已发送但未收到确认。
窗口的大小决定了发送方可以发送的数据包数量。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
计算机网络课程设计书计算机网络课程设计说明书（封面）学院名称：计算机与信息工程学院班级名称：网络工程一班学生：学号： 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滑动窗口用来暂存两台计算机间要传送的数据分组。
每台运行TCP协议的计算机有两个滑动窗口：一个用于数据发送，另一个用于数据接收。
发送端待发数据分组在缓冲区排队等待送出。
被滑动窗口框入的分组，是可以在未收到接收确认的情况下最多送出的部分。
滑动窗口左端标志X的分组，是已经被接收端确认收到的分组。
随着新的确认到来，窗口不断向右滑动。
滑动窗口算法工作过程如下：首先，发送方为每1帧赋一个序号（sequence number），记作SeqNum。
现在，我们忽略SeqNum是由有限大小的头部字段实现的事实，而假设它能无限增大。
发送方维护3个变量：发送窗口大小（send window size），记作SWS，给出发送方能够发送但未确认的帧数的上界；LAR表示最近收到的确认帧（last acknowledgement received）的序号；LFS表示最近发送的帧（last frame sent）的序号，发送方还维持如下的不变式：LAR-LFS≤SWS 。
2-1滑动窗口协议工作图窗口协议算法有三个功能：●在不可靠链路上可靠地传输帧●保持帧的传输顺序●支持流量控制2.2 选择重传协议在选择重传协议中，当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。
一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。
这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。
显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。
2-2 选择重传协议原理图三、过程论述(1）发送方程序流程图：3-1发送方程序流程图（2）接收方程序流程图：3-2接受方程序流程图3.2 功能实现（1）发送方程序：本程序设有四个变量：一是窗口大小变量，二是第一帧序列号变量，三是最近发送的帧变量，最后一个是最近收到的确认帧变量。
swpstate1.head=NULL; //变量初始值为空swpstate1.sendq=sendq_rear=(structsendq_slot*)malloc(sizeof(structsen dq_slot);if(!swpstate1.sendq) exit(1);sendq_rear->next=NULL;printf("请输入窗口大小：");scanf("%ld",&swpstate1.sws); //输入窗口大小swpstate1.rws=swpstate1.sws; //把窗口大小的值赋给变量if (swpstate1.sws>0){printf("请输入第一帧的序列号：");scanf("%ld",&swpstate1.hdr.seqnum); //输入第一帧序列号}swpstate1.nfe=swpstate1.hdr.seqnum; //把第一帧的值放进缓冲池sendp=(struct sendq_slot*) malloc (size of(struct sendq_slot));if(!sendp) exit(1);sendp->msg=swpstate1.hdr.seqnum;sendp->timeout=1;sendp->next=NULL;sendq_rear->next=sendp;sendq_rear=sendp;--swpstate1.sws;swpstate1.lfs=swpstate1.hdr.seqnum; //最近发送的帧取值r=swpstate1.hdr.seqnum; //最近收到的确认帧取值do{while(swpstate1.sws>0) //当窗口大小大于0时，执行以下的循环{sendp=(struct sendq_slot*)malloc(sizeof(struct sendq_slot)); if(!sendp) exit(1);sendp->msg=swpstate1.lfs+1; //如果输入的帧序号大于之前帧序号，那么窗口向前滑动sendp->timeout=1; //时延为1sendp->next=NULL;sendq_rear->next=sendp;sendq_rear=sendp;--swpstate1.sws;++swpstate1.lfs;}swpstate1.hdr.acknum=0; //ACK清空swpstate1.hdr.flags=0; //存储缓冲池清空printf("最近收到的ACK的帧序号：%ld\n",r);//输出最近收到的ACK帧序号printf("最近发送的帧序号（发送新帧后）：%ld\n",swpstate1.lfs);//输出最近发送帧序号（2）接收方的接收原则从总体上看是先判断输入的数据帧是否在接收围之，若是，则继续判断是否符合其他接收条件；若不是，则马上丢弃该数据帧，不再进行其他条件的判断。
struct sendq_slot *sendq_rear,*sendp,*p3,*p4; //设定变量struct recvq_slot *recvp,*recvq_rear,*p1,*p2;if(swpstate1.hdr.flags==0)//上次输入的数据帧被放置在缓存区，输入区被清空{do //如果继续接收数据帧则实施下面循环{printf("请输入收到的数据帧号：");scanf("%ld",&a);if(a>=swpstate1.nfe&&a<=swpstate1.lfs) //判断数据帧应被接收或缓存{if(swpstate1.head==NULL){recvp=recvq_rear=(structrecvq_slot*)malloc(sizeof(structrecvq_slot));recvp->next=NULL;swpstate1.head=recvp;}elseif(swpstate1.head!=NULL){recvp=(struct recvq_slot*)malloc(sizeof(struct recvq_slot));recvp->next=NULL;recvq_rear->next=recvp;recvq_rear=recvp;}}else{printf("所输数据不在接收窗口！");break; //跳出该循环}（3）若输入数据帧在接收围则继续判断并进行以下循环。
recvp->msg=a;if(recvp->msg==swpstate1.nfe) //是否放入缓存判断recvp->received=1;elserecvp->received=0;--swpstate1.rws;if(recvp->received==1) //数据帧被接收，则进行下面语句{ a=a-1;do{ a=a+1;if(swpstate1.head==NULL)break;p1=swpstate1.head;flag=0;while((a!=p1->msg)&&(p1->next!=NULL)){p2=p1;p1=p1->next;}if(a==p1->msg){flag=1;if(p1==swpstate1.head)swpstate1.head=swpstate1.head->next;else p2->next=p1->next;swpstate1.nfe=a+1;swpstate1.hdr.acknum=a+1;swpstate1.hdr.flags=1;}}while(flag==1);}printf("ACK号（期待的下一帧的序号）：%ld\n",swpstate1.nfe);printf("没按序接受的序号:\n");p1=swpstate1.head;while(p1!=NULL){printf("%ld\t",p1->msg);p1=p1->next;}（4）当接收完一个数据帧时，我们可以选择终止下面的继续接收，也可以选择继续接收。
如果继续接收，那么程序跳到判断循环，继续判断是否接收下一个数据帧，原理与上面相当。