停止等待协议java.docx
- 文档编号:7490448
- 上传时间:2023-01-24
- 格式:DOCX
- 页数:8
- 大小:20.30KB
停止等待协议java.docx
《停止等待协议java.docx》由会员分享,可在线阅读,更多相关《停止等待协议java.docx(8页珍藏版)》请在冰豆网上搜索。
停止等待协议java
竭诚为您提供优质文档/双击可除
停止等待协议,java
篇一:
停止等待协议实验报告
实验停止等待协议分析与协议模拟实现
一、实验目的和任务
1.掌握停止等待协议的原理及分析过程包括使用状态转移图进行协议的分析。
2.在计算机上编程模拟停止等待协议的工作过程并实现文件的端到端传输。
3.能够在文件的传输过程中表现出协议运行所遇到的各种状况,如丢包,差错控制等
二、分析与设计
1.设计任务分析:
停止等待协议是数据链路层的几个协议中最简单的协议,是具有最简单流量控制的数据链路层协议,是数据链路层各种协议的基础。
实验是基于winsock编程,是visualc++6.0win32控制台运用程序实现的。
它采用客户机/服务器(c/s)模型,即发送数据的一端为客户端,接收数据的一端为服务器端。
停止等待协议就是通过双方的收发数据而达到相互通信的目的。
本实验通过编程模拟实现停止等待协议,随机的发送文件,通过服务器的的接受结果和客户端的接受结果显示理解停止等待协议的原理,掌握其应用。
2.协议分析
假定1:
链路是理想的传输信道,所传送的任何数据既不会出差错也不会丢失。
假定2:
不管发方以多快的速率发送数据,收方总是来得及收下,并及时上交主机。
这个假定就相当于认为:
接收端向主机交付数据的速率永远不会低于发送端发送数据的速率。
如果存在这样的传输信道,数据链路层协议也是不需要的。
信道不会出错,而且接收方缓存的容量为无限大而永远不会溢出;或接收速率与发送速率绝对精确相等。
在上述两个假定的情况下,数据链路层当然就不需要任何协议就可以保证数据传输的正确。
这就是说,传输数据的信道是不可靠的(即不能保证所传的数据不产生差错),并且还需要对数据的发送端进行流量控制。
现在不能保证接收端向主机交付数据的速率永远不低于发送端发送数据的速率。
由收方控制发方的数据流收方每接受到发方一帧后,回复确认帧,让发方继续发送下一帧,并且收方将数据帧交给上层软件识别,出现错误就将帧丢掉.在大多数协议中,流量控制是一组过程,这组过程是用来告诉发送方在等待接收方的应答信号之前最多可以传送多少数据。
流量控制有两个要点:
(1)数据流不能使接收方过载。
任何接收设备都有一个处理输入数据的速率限制,并且存储输入数据的存储器容量也是有限的。
接收设备必须在达到这些限制之前通知发送设备并且请求发送设备发送较少的数据帧或是暂停一会儿。
在使用输入数据之前,需要对数据进行校验和处理,因此,每个接收设备都有一块存储器,叫做缓冲区,用于存放未来得及处理的数据帧。
如果缓冲区将满,接收方也必须能够通知发送方暂停传输,直到接收方又能接收数据。
(2)应答。
随着数据帧的到来,接收方对他们进行应答,可以每收到一帧给一个应答,也可以一次对若干帧进行应答。
如果一个帧到达时已经被破坏,接收方发送一个否定应答帧(nak)。
在数据链路层,差错控制主要指错误检测和重传方法。
在一个帧中出现任何一个错误,接收方就返回一个否定应答帧,出错的帧就被发送方重新传送。
这个过程被称作自动重复请求(aRq)。
数据被重传的情况有三种:
帧破坏、帧丢失和应答帧丢失。
流量控制和差错控制是结合在一起实现的,共有两种实现流量控制和差错控制的技术:
停止等待协议和滑动窗口协议。
可以用多种方法来表示一个有限状态机,对协议进行描述,以下只描述一种。
1)混合描述方法
比较实用的办法是合并一些状态,即考虑一些次要的细节。
例如,甲方的状态1和状态2,状态3和状态4都可以合并,乙的状态1和状态4,状态2和状态3也可进行合并。
这样可以用3个字符xyz表示整个系统的状态,其中x=0或1,对应于甲方准备发[0]或[1](包括发完后等待ack的状态);y=0或1,对应于乙方期望收到[0]或[1];z=0、l、a或-,对应于信道上传送的是[0]、[1]、ack或出现了差错(包括丢失)。
这样,就可得出图3-24的有限状态机。
在弧线(或直线)旁边注明的数字为状态变迁的标号,其意义也注明在图3-24的右方。
假设系统一开始处在(000)状态。
这表示甲发完[0],乙期望收到[0],而信道上传送的也是[0]。
在无差错的情况下,系统的状态仅在4个状态中循环:
(000)→(01a)→(111)→(10a)→(000)→‥‥。
从理论上讲,应当共有2×2×4=16种不同的状态。
去掉没有意义的组合后,还剩下10种状态,而导致状态变迁的输人事件共有9种(标号0~8)。
这种有限状态机可帮助我们检查协议是否正确。
例如,检查一下乙方会不会连续将两个0号帧送交主机。
这相当于检查一下会不会出现这种情况,即在两次出现状态变迁1之间不出现状态变迁3。
仔细检查图3-24就可发现这种情况是不会发生的。
同样方法也可用来排除连续将两个1号帧送交主机的可能。
再检查一下会不会发生甲方连续改变状态2次(如从0到1,再回到0)而乙方的状态未改变。
这种情况相当于出现了未被发现的报文丢失。
可以看出,这种情况也是不存在的。
协议必须不出现死锁。
死锁的出现是因为存在着这样的一种状态子集,其特点是:
从这一子集内变迁到子集外是不可能的,而在这一子集内状态的变迁总是局限于子集内的几个状态。
可以看出,如图所示的自动机没有死锁现象。
3.设计方案论证
当收方收到一个正确的数据帧后,便会向发方发送一个确认帧ack,表示发送的数据正确接收。
当发方收到确认帧后才能发送一个新的数据帧,这样就实现了接收方对发送方的流量控制。
由于通信线路质量各方面的影响,数据帧从发送方到接收方传输的过程中可能会出现差错。
为了保证数据的正确性和完整性,接收方在收到数据后,会用一定的方法对接收到的数据进行差错检验,所以接收方很容易检测出收到的数据帧是否出现差错。
当接收方发现收到的数据出现差错时,就会向发送方发送一个否认帧nak,表示对方发送的数据错误。
发送方会根据接收方发来的信息做出相应的操作。
采用这样的有效的检错机制,数据链路层可以对上面的网络层提供了可靠的传输的服务。
三、系统运行与验证
程序分两部分:
客户程序和服务器程序。
工作过程是:
服务器首先启动,它创建套接字之后等待客户的连接;客户启动后创建套接字,然后和服务器建立连接;建立连接后,客户写入文件的路径,然后将文件发送到服务器,服务器要求写入保存的文件路径,收到到文件后,将接收到的文件保存到指定路径当中。
服务器端运行图:
客户端运行图
成功发送文件后的
服务器端
客户端
文件发送失败
客户端的响应
客户端向服务器端发送文件请求enq,但是没有收到返回帧,客户端显示sendfilefailed,而filesendfailed表明文件经过规定次数重传后文件还是发送失败。
四、总结与体会
1.分组情况
张润:
负责停止等待协议模拟客户端程序的编写、调试。
毛凤阳:
负责停止等待协议模拟服务端程序的编写、调试。
黄晓明:
负责查阅相关资料,实验报告的撰写,编写头文件。
2.总结
通过本次实验及课上老师讲解,对停止等待协议有了更深刻的了解。
并且通过c/s代码的编写运行,形象地看到客户/服务器端的运作方式,对于c/s模型有了很深刻的印象以及进一步理解。
通过代码的编写,再一次熟悉socket编程原理,掌握简单的套接字编程。
运行程序成功后,是在同一台电脑上进行c与s端的连接。
而且使用的是tcp协议,所以要模拟停止等待协议发送丢包,超时等情况比较困难。
仅仅实现了文件发送时等待应答信号超时的情况。
编程时遇到许多困难,从一个新手通过查阅相关的资料和以前的学习以及和同学之间的交流进步到逐步了解。
在设计过程中,组员之间相互促进,相互交流,共同进步。
篇二:
停止等待协议的实现
福建农林大学计算机与信息学院
课程名称:
课程设计题目:
姓名:
系:
专业:
年级:
学号:
指导教师:
职称:
课程设计报告计算机网络停止等待协议的实现计算机计算机科学与技术
20xx年6月10日
福建农林大学计算机与信息学院
课程设计报告结果评定
目录
1、课程设计的目的和任务·················································································································4
2、课程设计的要求····························································································································4
3、课程设计的分析与设计···············································································································4
3.1设计任务分析·····················································································································4
3.2设计方案论证·····················································································································5
3.3详细设计····························································································································5
3、系统实施········································································································································7
4、总结与体会····································································································································9
5、参考文献········································································································································9附录:
源代码····································································································································10
停止等待协议的实现
1、课程设计的目的和任务
《计算机网络》课程讲述计算机网络的原理,尤其是tcp/ip协议栈的原理和应用,是一门理论性、应用性、实践性都比较强的课程。
而此次的课程设计是在学习完《计算机网络》课程后进行的一次全面的综合能力的检验。
计算机网络的课程设计是从原理和实践的角度,在计算机上编程模拟实现计算机网络的基本协议。
通过本次课程设计,使我们对计算机网络的原理能有更加深刻的认识和理解,同时进一步锻炼自己的动手能力。
在这次课程设计中,我设计的的是通过编译语言,编程模拟实现数据链路层协议中的停止等协议。
2、课程设计的要求
通过双方的收发数据而达到相互通信的目的。
3、课程设计的分析与设计
3.1设计任务分析
停止等待协议是数据链路层的几个协议中最简单的协议,是具有最简单流量控制的数据链路层协议,是数据链路层各种协议的基础。
此课程设计是基于winsock编程,是在Vc++6.0的mFc界面下和控制台下实现的。
它采用客户机/服务器(c/s)模型,即发送数据的一端为客户端,接收数据的一端为服务器端。
停止等待协议就是通过双方的收发数据而达到相互通信的目的。
本课程设计通过编程模拟实现停止等待协议,随机的发送数据,通过服务器的的接受结果和客户端的接受结果显示理解停止等待协议的原理,掌握其应用。
3.2设计方案论证
当收方收到一个正确的数据帧后,便会向发方发送一个确认帧ack,表示发送的数据正确接收。
当发方收到确认帧后才能发送一个新的数据帧,这样就实现了接收方对发送方的流量控制。
由于通信线路质量各(停止等待协议,java)方面的影响,数据帧从发送方到接收方传输的过程中可能会出现差错。
为了保证数据的正确性和完整性,接收方在收到数据后,会用一定的方法对接收到的数据进行差错检验,所以接收方很容易检测出收到的数据帧是否出现差错。
当接收方发现收到的数据出现差错时,就会向发送方发送一个否认帧nak,表示对方发送的数据错误。
发送方会根据接收方发来的信息做出相应的操作。
采用这样的有效的检错机制,数据链路层可以对上面的网络层提供了可靠的传输的服务。
3.3详细设计
停止等待协议的算法如下:
为了对停止等待算法有一个完整而准确的理解,下面给出此协议的算法。
具有最简单流量控制的数据链路层协议
假定1:
链路是理想的传输信道,所传送的任何数据既不会出差错也不会丢失。
假定2:
不管发方以多快的速率发送数据,收方总是来得及收下,并及时上交主机。
这个假定就相当于认为:
接收端向主机交付数据的速率永远不会低于发送端发送数据的速率。
现在去掉上述的第二个假定。
但是,仍然保留第一个假定,即主机a向主机b传输数据的信道仍然是无差错的理想信道。
然而现在不能保证接收端向主机交付数据的速率永远不低于发送端发送数据的速率。
由收方控制发方的数据流,乃是计算机网络中流量控制的一个基本方法。
简单解释:
收方每接受到发方一帧后,回复确认帧,让发方继续发送下一帧,并且收方将数据帧交给上层软件识别,出现错误就将帧丢掉.
在接收结点:
(1)等待。
(2)若收到由发送结点发过来的数据帧,
篇三:
实验停止等待协议分析与协议模拟实现
实验停止等待协议分析与协议模拟实现
一、实验目的
1)了解停止等待协议的原理
2)掌握协议分析的方法和过程
3)通过程序模拟停止等待协议的工作过程
二、实验要求
1)根据示例,编写停止等待协议的模拟程序,演示停止等待协议的工作过程。
2)撰写实验报告。
三、协议概述
如果链路是理想的传输信道,1)所传送的任何数据既不会出差错也不会丢失;2)如果不管发送方以多快的速率发送数据,接收方总是来得及收下,并及时上交主机。
如果存在这样的传输信道,数据链路层协议也是不需要的。
信道不会出错,而且接收方缓存的容量为无限大而永远不会溢出;或接收速率与发送速率绝对精确相等。
在上述两个假定的情况下,数据链路层当然就不需要任何协议就可以保证数据传输的正确。
这就是说,传输数据的信道是不可靠的(即不能保证所传的数据不产生差错),并且还需要对数据的发送端进行流量控制。
在大多数协议中,流量控制是一组过程,这组过程是用来告诉发送方在等待接收方的应答信号之前最多可以传送多少数据。
流量控制有两个要点:
(1)数据流不能使接收方过载。
任何接收设备都有一个处理输入数据的速率限制,并且存储输入数据的存储器容量也是有限的。
接收设备必须在达到这些限制之前通知发送设备并且请求发送设备发送较少的数据帧或是暂停一会儿。
在使用输入数据之前,需要对数据进行校验和处理,因此,每个接收设备都有一块存储器,叫做缓冲区,用于存放未来得及处理的数据帧。
如果缓冲区将满,接收方也必须能够通知发送方暂停传输,直到接收方又能接收数据。
(2)应答。
随着数据帧的到来,接收方对他们进行应答,可以每收到一帧给一个应答,也可以一次对若干帧进行应答。
如果一个帧到达时已经被破坏,接收方发送一个否定应答帧(nak)。
在数据链路层,差错控制主要指错误检测和重传方法。
在一个帧中出现任何一个错误,接收方就返回一个否定应答帧,出错的帧就被发送方重新传送。
这个过程被称作自动重复请求(aRq)。
数据被重传的情况有三种:
帧破坏、帧丢失和应答帧丢失。
流量控制和差错控制是结合在一起实现的,共有两种实现流量控制和差错控制的技术:
停止等待协议和滑动窗口协议。
【图解】
【总结】使用的链路层传输控制协议
发方:
发送一个数据帧后,必须等待收方的确认帧才可以发送下一个数据帧;
为防止发送的数据或该数据的确认帧丢失,发方内部设置一个定时器,当超过定时时间发方仍未收到确认帧时,发方重发该帧;
为防止确认帧丢失而造成收方收到重复帧的情况,发方给每一个数据帧带上一个序列号。
(1个比特位)
收方:
在收方接收错误时,收方发一否认帧,要求发方重发该帧;
收方收到相同的两帧时,丢掉该数据帧并重发确认帧。
【流程示意图】
发送方
发送数据包
接收方发送方发送数据包接收方
接收数据包1正确
发送正确认ack
接收正确认发送数据包接收数据包2错误
发送负确认nak
接收负确认重发数据包接收数据包2正确
接收正确认发送数据包接收数据包3正确
发送正确认ack
接收正确认发送正确认ack超时重传数据包接收正确认接收数据包0正确发送正确认ack1超时超时接收数据包1正确发送正确认ack0接收数据包1正确(抛弃)发送正确认ack0接收正确认发送数据包
图a停止等待协议的基本工作过程图b数据包的丢失和确认信息的丢失示意图
四、协议分析
可以用多种方法来表示一个有限状态机,对协议进行描述。
以下是在某种假定条件下的协议分析。
1)状态迁移图
设甲、乙双方进行半双工通信,甲发信息帧,乙回送确认帧。
双方约定采用停止等待协议,因此甲方仅需用1比特来编号。
下面将0号帧和1号帧分别记为[0]和[1]。
当收到有差错的帧时,则丢弃此帧,同时不发任何应答帧。
当收到无差错的帧但序号不正确时,要发确认帧,同时要丢弃此帧,不送主机。
我们还假定收方在准备发送确认帧ack时,暂不接收外面发来的帧。
这样,我们就得出甲乙双方各自的有限状态机,如下图所示。
图中椭圆形符号为状态符号,其右方数字为状态标号,椭圆形内的字表示状态的意义。
带箭头的直线或弧线表示状态的变迁,而直线或弧线旁边的字代表自动机的输入事件。
例如,甲方自动机中的“发[0]”就是一个输入事件。
图中在某些方面进行了一些简化。
例如,当乙方处于“期望收[0]”的状态时,若收到无差错的[1]帧,仍然应当先进入“准备发ack”状态,然后才发出ack。
但这里就将“收[1]”与“发ack”合并成为一个事件。
其余部分不再详述。
2)状态迁移表方法
除状态转移图之外,还可用状态迁移表(又称为判决表)来表示自动机的工作。
例如对甲方的自动机,可得出如下表所示的状态变迁表。
表中的项目代表“新的状态/输出”。
例如在状态为x1时,若输入为“发[0]”,则状态从x1转为x2,同时输出为“[0]帧”。
当输出为“-”时表示无输出。
3)混合描述方法
比较实用的办法是合并一些状态,即考虑一些次要的细节。
例如,甲方的状态1和状态2,状态3和状态4都可以合并,乙的状态1和状态4,状态2和状态3也可进行合并。
这样可以用3个字符xyz表示整个系统的状态,其中x=0或1,对应于甲方准备发[0]或[1](包括发完后等待ack的状态);y=0或1,对应于乙方期望收到[0]或[1];z=0、l、a或-,对应于信道上传送的是[0]、[1]、ack或出现了差错(包括丢失)。
这样,就可得出图3-24的有限状态机。
在弧线(或直线)旁边注明的数字为状态变迁的标号,
其意义也注明在图3-24的右方。
假设系统一开始处在(000)状态。
这表示甲发完[0],乙期望收到[0],而信道上传送的也是[0]。
在无差错的情况下,系统的状态仅在4个状态中循环:
(000)→(01a)→(111)→(10a)→(000)→‥‥。
从理论上讲,应当共有2×2×4=16种不同的状态。
去掉没有意义的组合后,还剩下10种状态,而导致状态变迁的输人事件共有9种(标号0~8)。
这种有限状态机可帮助我们检查协议是否正确。
例如,检查一下乙方会不会连续将两个0号帧送交主机。
这相当于检查一下会不会出现这种情况,即在两次出现状态变迁1之间不出现状态变迁3。
仔细检查图3-24就可发现这种情况是不会发生的。
同样方法也可用来排除连续将两个1号帧送交主机的可能。
再检查一下会不会发生甲方连续改变状态2次(如从0到1,再回到0)而乙方的状态未改变。
这种情况相当于出现了未被发现的报文丢失。
可以看出,这种情况也是不存在的。
协议必须不出现死锁。
死锁的出现是因为存在着这样的一种状态子集,其特点是:
从这一子集内变迁到子集外是不可能的,而在这一子集内状态的变迁总是局限于子集内的几个状态。
可以看出,图3-24所示的自动机没有死锁现象。
有限状态机模型的缺点就是当描述比较复杂的协议时,状态的数目将急剧增加,以致很难用它来清晰地描述协议。
五、协议验证
协议的“验证”一词包括了“validation”与“verification”,包括了协议语法和语义的验证。
一般说来,协议的验证包括以下几个方面的内容:
(l)可达性(reachability)验证协议的各种可能状态之间的可达关系。
如果从状态a到状态b的变迁不可能发生(直接或间接),则从状态a到状态b是不可达的。
如果协议从初始状态到某个状态不可达,则表明协议有错误。
(2)死锁最典型的死锁是协议中各实体都处于这样的一种等待状态,即只有在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 停止 等待 协议 java