课程设计报告-滑动窗口协议仿真-精品.doc

上传人:b****9 文档编号:142448 上传时间:2022-10-04 格式:DOC 页数:30 大小:458.51KB
下载 相关 举报
课程设计报告-滑动窗口协议仿真-精品.doc_第1页
第1页 / 共30页
课程设计报告-滑动窗口协议仿真-精品.doc_第2页
第2页 / 共30页
课程设计报告-滑动窗口协议仿真-精品.doc_第3页
第3页 / 共30页
课程设计报告-滑动窗口协议仿真-精品.doc_第4页
第4页 / 共30页
课程设计报告-滑动窗口协议仿真-精品.doc_第5页
第5页 / 共30页
点击查看更多>>
下载资源
资源描述

课程设计报告-滑动窗口协议仿真-精品.doc

《课程设计报告-滑动窗口协议仿真-精品.doc》由会员分享,可在线阅读,更多相关《课程设计报告-滑动窗口协议仿真-精品.doc(30页珍藏版)》请在冰豆网上搜索。

课程设计报告-滑动窗口协议仿真-精品.doc

滁州学院

课程设计报告

课程名称:

计算机网络

设计题目:

滑动窗口协议仿真

系别:

计算机与信息工程学院

专业:

计算机科学与技术

组别:

第五组

起止日期:

2011年11月24日~2011年12月7日

指导教师:

赵国柱

计算机与信息工程学院二○一一年制

课程设计题目

滑动窗口协议仿真

组长

赵育坤

学号

2011220135

班级

计专1班

系别

计算机与信息工程学院

专业

计算机科学与技术

组员

闫婷、张侠、余静、于东锋、张飞、赵育坤

指导教师

赵国柱

课程设计目的

掌握滑动窗口协议的基本原理,并能够用所学计算机高级语言进行编程模拟

课程设计所需环境

开发环境:

 VC++运行环境:

Windows操作系统

课程设计任务要求

1.程序按照滑动窗口协议实现端对端的数据传送。

包括协议的各种策略,如包丢失、停等应答、超时等都应有所仿真实现

2.显示数据传送过程中的各项具体数据。

双方帧的个数变化,帧序号,发送和接受速度,暂停或重传提示等

课程设计工作进度计划

序号

起止日期

工作内容

分工情况

1

11月24号~11月27号

了解工作要求,明确分工内容,网上查阅相关资料

所有组员共同参与

2

11月28号~11月30号

sender队列模块的编写

由闫婷完成

3

12月1号~12月4号

sender主函数的编写

由赵育坤、张飞完成

4

11月28号~11月30号

receiver队列模块的编写

由张侠完成

5

12月1号~12月4号

receiver主函数的编写

由余静、于东锋完成

6

12月5号~12月7号

最后汇总,调试

由赵育坤、于东锋完成

指导教师签字:

年月日

教研室审核意见:

教研室主任签字:

年月日

课程设计任务书

一.引言

二.基本原理

2.1窗口机制

2.21bit滑动窗口协议

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协议。

为了解决这个问题,又提出了选择重传协议。

当接收方发现某帧出错后,继续接受后面送来的正确的帧,只是不交付它们,存放在自己的缓冲区中,并且要求发送方重传出错的那一帧。

一旦收到重传来的帧后,就可以将存于缓冲区中的其余帧一并按正确的顺序递交给主机。

2.基本原理

2.1窗口机制

滑动窗口协议的基本原理就是在任意时刻,发送方都维持了一个连续的允许发送的帧的序号,称为发送窗口;同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。

发送窗口和接收窗口的序号的上下界不一定要一样,甚至大小也可以不同。

不同的滑动窗口协议窗口大小一般不同。

发送方窗口内的序号代表了那些已经被发送,但是还没有被确认的帧,或者是那些可以被发送的帧。

接受方为其窗口内的每一个序号保留了一个缓冲区。

与每个缓冲区相关联的还有一位,用来指明该缓冲区是满的还是空的。

若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议,它们的差别仅在于各自窗口尺寸的大小不同而已。

1比特滑动窗口协议:

发送窗口=1,接收窗口=1;后退N协议:

发送窗口>1,接收窗口=1;选择重传协议:

发送窗口>1,接收窗口>1。

2.21bit滑动窗口协议

当发送窗口和接收窗口的大小固定为1时,滑动窗口协议退化为停等协议(stop-and-wait)。

该协议规定发送方每发送一帧后就要停下来,等待接收方已正确接收的确认(acknowledgement)返回后才能继续发送下一帧。

由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧,因此发送方要为每一个帧加一个序号。

由于停等协议规定只有一帧完全发送成功后才能发送新的帧,因而只用一比特来编号就够了。

其发送方和接收方运行的流程图如图所示。

2.3后退N协议

由于停等协议要为每一个帧进行确认后才继续发送下一帧,大大降低了信道利用率,因此又提出了后退n协议。

后退n协议中,发送方在发完一个数据帧后,不停下来等待应答帧,而是连续发送若干个数据帧,即使在连续发送过程中收到了接收方发来的应答帧,也可以继续发送。

且发送方在每发送完一个数据帧时都要设置超时定时器。

只要在所设置的超时时间内仍收到确认帧,就要重发相应的数据帧。

如:

当发送方发送了N个帧后,若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息,则该帧被判为出错或丢失,此时发送方就不得不重新发送出错帧及其后的N帧。

从这里不难看出,后退n协议一方面因连续发送数据帧而提高了效率,但另一方面,在重传时又必须把原来已正确传送过的数据帧进行重传(仅因这些数据帧之前有一个数据帧出了错),这种做法又使传送效率降低。

由此可见,若传输信道的传输质量很差因而误码率较大时,连续测协议不一定优于停止等待协议。

此协议中的发送窗口的大小为k,接收窗口仍是1。

2.4选择重传协议

在后退n协议中,接收方若发现错误帧就不再接收后续的帧,即使是正确到达的帧,这显然是一种浪费。

另一种效率更高的策略是当接收方发现某帧出错后,其后继续送来的正确的帧虽然不能立即递交给接收方的高层,但接收方仍可收下来,存放在一个缓冲区中,同时要求发送方重新传送出错的那一帧。

一旦收到重新传来的帧后,就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。

这种方法称为选择重发(SELECTICEREPEAT),其工作过程如图所示。

显然,选择重发减少了浪费,但要求接收方有足够大的缓冲区空间。

2.5流量控制

TCP的特点之一是提供体积可变的滑动窗口机制,支持端到端的流量控制。

TCP的窗口以字节为单位进行调整,以适应接收方的处理能力。

处理过程如下:

(1)TCP连接阶段,双方协商窗口尺寸,同时接收方预留数据缓存区;

(2)发送方根据协商的结果,发送符合窗口尺寸的数据字节流,并等待对方的确认;

(3)发送方根据确认信息,改变窗口的尺寸,增加或者减少发送未得到确认的字节流中的字节数。

调整过程包括:

如果出现发送拥塞,发送窗口缩小为原来的一半,同时将超时重传的时间间隔扩大一倍。

(4)滑动窗口机制为端到端设备间的数据传输提供了可靠的流量控制机制。

然而,它只能在源端设备和目的端设备起作用,当网络中间设备(例如路由器等)发生拥塞时,滑动窗口机制将不起作用。

3.需求分析

3.1课程设计题目:

滑动窗口协议仿真

3.2开发环境:

VisualC++6.0

3.3运行环境:

Windows操作系统

3.4课程设计任务及要求:

(1)程序按照滑动窗口协议实现端对端的数据传送。

包括协议的各种策略,如包丢失、停等应答、超时等都应有所仿真实现。

(2)显示数据传送过程中的各项具体数据。

双方帧的个数变化,帧序号,发送和接受速度,暂停或重传提示等。

3.5界面要求:

此次课程设计要求的所有功能应可视,我们组主要是用VC++编写的,运行在DOS环境下,观察发送方(sender)发送数据包到接收方(receive)时。

界面应显示出双方帧个数的变化,帧序号,发送和接受速度,暂停或重传提示等,界面中必须动态显示数据帧的发送和接受情况,包括在相应的窗口详细显示相应的ACK和其他收发数据帧后发出的消息,以表明模拟协议的正确运作过程。

在各种情况下,接受方和发送方窗口应实时显示帧的发送和接受情况,包括序号,时间戳,内容等。

以及窗口的填充和清空情况。

3.6网络接口要求:

两台机器或是一台机器中两个独立的线程模拟发送方与接受方,接收数据的端口初始应为监听状态。

发送方向接受方发起连接,成功后开始发送数据。

4.概要设计

4.1结构体定义如下:

typedefenum{data=1,ack,nak,tout}frame_kind;//帧类型

typedefstructframe_head

{

frame_kindkind;//帧类型

unsignedintseq;//序列号

unsignedintack;//确认号

unsignedchardata[MAX_LENGTH];//数据

}Head;

typedefstructframe

{

frame_headhead;//帧头

unsignedintsize;//数据的大小

}Frame;

typedefstructframenode//队列节点类型

{

framehead_data;

structframenode*next;

}Framenode;

typedefstruct

{

Framenode*front;//队头指针

Framenode*rear;//队尾指针

}LinkQueue;

4.2发送方的主要函数实现:

函数名:

voidInitLine(LinkQueue*q);

功能:

初始化队列。

函数名:

voidGetFrameFromHost(LinkQueue*q);

功能:

从主机取数据帧,由于实验需要,假设主机有足够多的数据帧要发送。

voidDeLine(LinkQueue*q);

功能:

数据帧发送完毕(收到确认帧)后,删除发送的数据帧(队头)。

函数名:

intQueueEmpty(LinkQueue*q);

功能:

判断队列是否为空。

函数名:

frameQueueFront(LinkQueue*q);

功能:

取队头,首帧是准备好待发送的帧。

函数名:

intQueueLen(LinkQueue*q);

功能:

计算队列长度。

函数名:

DWORDWINAPIReceiveF

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 解决方案

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1