连续ARQ协议的交付过程

　　连续ARQ协议在使用过程中如何完成滑动窗口和请求重发呢？下面我们就在它的主要功能方面进行一个详尽的描述。希望大家能够通过本文的一些内容对这个流程以及交付过程有一个了解。

　　回退n帧(go-back-n)GBN,以及选择性重传(selective repeat)ARQ,两种协议是滑动窗口技术与请求重发技术的结合,由于窗口尺寸开到足够大时,帧在线路上可以连续地流动,因此又称其为连续ARQ协议? 连续重发请求ARQ方案是指发送方可以连续发送一系列信息帧,即不用等前一帧被确认便可继续发送下一帧,效率大大提高?但在这种重发请求方案中,需要在发送方设置一个较大的缓冲存储空间(称作重发表),用以存放若干待确认的信息帧?

　　当发送方收到对某信息帧的确认帧后,便可从重发表中将该信息帧删除?所以,连续重发请求ARQ方案的链路传输效率大大提高,但相应地需要更大的缓冲存储空间? 在这一协议中,当发送站点发送完一个数据帧后,不是停下来等待应答帧,而是可以连续再发送若干个数据帧?如果在此过程中又收到了接收端发来的应答帧,那么还可以接着发送数据帧?由于减少了等待时间,整个通信的吞吐量就提高了?

　　连续ARQ协议的主要功能可以归结为以下两点:

　　1.在不可靠的链路上实现可靠交付?

　　这点可从用下面的图来说明?

不可靠的链路上实现可靠交付

　　因为出错的帧都被CRC检验器悄悄地丢弃了,因此接收端收下的帧都是无传输差错的帧?数据链路层协议还保证了收到的帧的顺序和发送端发送的顺序一致,因为序号不对的帧都不接受?因此,数据链路层的连续ARQ协议就在不可靠的链路上实现了可靠交付,即发送端发送什么,接收端就收到什么?所有的重传对上面都是透明的?

　　总之,可靠交付就是:无差错?无丢失?无重复?按顺序?

　　2. 支持了流量控制?

　　在链路层流量控制的思想就是:当接收端来不及接收时(如缓存空间不够或CPU忙不过来),就可以通过暂时不发送确认帧来降低发送端发送数据帧的速率?

　　关于连续ARQ协议特别要注意的地方就是对出错帧和不按序到达的帧的处理?

　　对出错帧的处理:

　　CRC检验器自动将其丢弃,协议没有其他动作?但为了不白白浪费时间,可以规定,如果一个帧重传多少次都一直出错,那么就不要再继续重传下去,而是报告上层软件,指出通信线路不可用?

　　对不按序到达的帧的处理(这个帧并无传输差错):

　　如果接收端没有数据帧要发送,接收端丢弃这个帧,同时向发送端重复发送已经发送过的最后一个确认帧?

　　如果接收端有数据帧要发送,接收端可以在下面要发送的自己的数据帧中,把确认信息捎带发送给对方?这个确认信息就是期望收到对方的某个编号的数据帧?

　　接收端也可以每隔一段时间,向发送端重复发送已经发送过的最后一个确认帧?