[合同协议]3、停等协议.pptVIP

停等协议 最简单的停等（stop-and-wait）协议 这个协议规定发送方每发送一帧后就要停下来，等待对方已正确接收的确认（Acknowledgement，Ack）帧返回后才能继续发送下一帧 (下面使用类java语言) 停等协议 对前面的改进： 必须将发送的数据帧编以序号来区分是新发送的帧还是重新发送的帧 确认帧Ack也应加上序号以表示是确认哪一帧 用类JAVA代码来描述己加上数据帧序号和确认帧序号的停等协议执行过程，如后面一页所示： 停等协议 停等协议 停等协议的最大缺点是由于发送方要停下来等待Ack返回后再继续发送而造成信道的浪费。 设信道容量是B bps，帧长度为L bits，信号在信道中的往返传播延迟时间（propagation delay）是2R，并假定返回的Ack帧很短，不占用信道时间。在一个周期中实际用于发送的时间是L/B。而空等待的时间是2R。因此，信道的实际有效利用率只有 实际上，若由于信道差错而收不到Ack而造成超时重传以及有效传送的数据必须加上帧头（包括用于校验的冗余位）构成帧来发送，它们也都会造成信道有效利用率的损失。 B为信道容量（b/s） R为单程传播延迟时间（s） L为数据帧长度（bits） 并设 D为帧内有效数据的长度（bits） H为帧头的长度（bits） 显然有，L=H+D。 另外，可以认为Ack帧不含有用户数据，故其长度亦为H。又令 T表示等待Ack的超时间隔时间（s） P1和P2分别表示数据帧和Ack帧出错或丢失的概率 则每个数据帧不能正确发送和收到确认ACK的概率为 从而可求得最终发送成功所需的平均发送次数为 或者说，平均重传次数为 停等协议的捎带确认 * * Sender while (1) { transmit (frame); try { receive (ack); } catch (timeout) { retransmit (frame); } get new frame } Receiver while (1) { receive (frame); transmit (ack); } Sender next_frame_to_send= 0; while (1) { transmit (frame next_frame_to_send); try { while (1) { receive (ack n); if (n != next_frame_to_send) continue; } } catch (timeout) { retransmit(frame); } next_frame_to_send ++; } Receiver frame_expected = 0; while (1) { receive (frame n); ack (frame n); if (n != frame_expected) continue; frame_expected ++; } 再加上接收方校验的过程后停等协议发送方和接收方运行的流程示意图 接受方 0→期待帧号 期待帧号⊕1→期待帧号 恢复报文送主机 等待 校验和检查 收到帧的Seq =期待帧号 确认帧号Ack = Seq (返回) 不对 对 对 不对 数据帧到达 0→发送帧号 从主机取报文 装配帧 (seq = 发送帧号) 发送,并置计时器 等待 Ack = 发送帧号 发送帧号⊕1→发送帧号 发送方 对 不对 计时器超时 发送数据帧 返回Ack帧 停等协议的信道利用率 推导过程： 第1次-----1-P 第2次-----p(1-P) 第3次-----p2(1-p) …. 第K次-----P(K-1)(1-P) 在 时间内，真正用来发送有效用户数据的时间仅为D / B ，即信道有效利用率为 信通利用率的分析 超时间隔T必须取得足够大，即T≥H/B +2R，才能使得在发送成功时不会由于太早超时而误重传。为了使U达到最大，可取 T= H/B +2R。此时有 为了信道利用效率最高，有效数据的长度D=SQRT((H+BT)/E) ----B为信道容量，T为往返传播时延，E为每比特的误码率