java利用停止等待协议传输文件_停止等待协议

停止等待协议

理想传输条件有以下两个特点：

传输信道不产生差错

不管发送发以多快的速度发送数据，接收方总是来得及处理收到的数据。

然而实际的网络都不具备以上两个理想条件，所以需要一个协议

“停止等待协议”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送以一个分组

全双工通信的双方既是发送发也是接收方

为了讨论问题的方便，我们仅考虑A发送数据而B接受数据并发送确认。因此A叫做发送方，而B叫做接收方

无差错情况

A发送分组M1，发完就暂停发送，等待B的确认(ACK)。B收到了M1向A发送ACK。A在收到了对M1的确认后，就再发送下一个分组M2

出现差错

B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做(不通知 A 收到有差错的分组)。

M1在传输过程中丢失了，这时B当然什么都不知道，也什么不做

如何确保B正确收到M1呢？

解决方法：超时重传

A为每一个已发送的分组都设置一个超时计时器

A只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组

确认丢失

若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内不能收到确认，但 A 并无法知道：是自己发送的分组出错、丢失了，或者 是B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。

假定B又收到了重传的分组M1。这是B应该采取两步行动

丢弃这个重复的分组M1, 不向上层交付

向A发送确认。不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示A没有对M1的确认

确认迟到

传输过程中没有出现差错，但B对分组M1的确认迟到了。

A会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃

B任然会收到重复的M1，并且同样要丢弃重复的M1，并重传确认分组

注意

在发送完一个分组后，必须暂时保留已发送的分组副本，以备重发

分组和确认分则都必须编号

超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些

流水线传输

停止等待协议的优点是简单，缺点是信道利用率太低。为了提高传输效率，可以采用流水线传输

累积确认

接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。

优点：容易实现，即使确认丢失也不必重传。

缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。