前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >3.4.2 单帧滑动窗口与停止等待协议

3.4.2 单帧滑动窗口与停止等待协议

作者头像
week
发布2018-08-24 16:32:32
1.3K0
发布2018-08-24 16:32:32
举报
文章被收录于专栏:用户画像

在停止等待协议中,源站发送单个帧后必须等待确认,在目的站的回答到达源站之前,源站不能发送其他的数据帧。从滑动窗口机制的角度看,停止等待协议相当于发送窗口和接受窗口的接受窗口大小均为1的滑动窗口协议。

在停止等待协议中,除了数据帧丢失,还可能出现以下两种差错:

到达目的站的帧可能已遭破坏,接受站利用在前面讨论过的差错检测技术检出后,简单地将该帧丢弃。为了对付这种可能发生的情况,源站装备了计时器,在一个帧发送之后,源站等待确认,如果在计时器计满时仍未收到确认,则再次发送同样的帧。如此重复,直到该数据帧无错误地到达为止。

 另一个可能的差错是数据帧正确而确认被破坏。为了避免这样的问题,发送的帧交替地用0和1来标识,肯定确认则分别用ACK0和ACK1来表示,当收到的确认有误时,则重传已发送的帧。下面分析停止等待协议的实现步骤。

在发送结点:

1 从主机取一个数据帧,送交发送缓冲。

2 V(s)<---0。{发送状态V(S)初始化}

3 N(s)<---V(S):{将发送状态变量值写入数据帧的发送序列号N(s) }

4 将发送缓存中的数据帧发送出去。{这个数据帧的副本仍保留在发送缓存中}

5 设置超时计时器。{选择适当的超时重传时间Tout}

6 等待。{等待以下7和8这两个事件中最先出现的一个}

7 若收到确认帧ACKn,

若n=1-V(s),则:{已发送的数据帧被接收方确认}

从主机取一个新的数据帧,放入发送缓存;

V(s)<---[1-V(s)],转到4.{更新发送状态变量,变为下一个序号}

否则,丢弃这个确认帧,转到6.{这说明已发送的数据帧没有被接收方确认}

8 若超时计数器时间到,则转到4。{重传已发送的数据帧}

在接受结点:

1.V(R)<---0.{接受状态变量初始化,其数值等于欲接受的数据帧的发送序列}

2.等待

3.收到一个数据帧,就检查有无产生传输差错(如用CRC)。

若检查结果正确无误(否则直接丢弃,转2),则执行后续算法;

4.若N(s)=V(R),则执行后续算法;{收到发送序号正确的数据帧}

否则丢弃此数据帧,然后转到7。{丢弃的数据帧就是重复帧}

5.将收到的数据帧中的数据部分送交主机。

6.V(R)<---[1-V(R)]。{更新接受状态变量,准备接受下一个数据帧}

7.发送确认帧ACKn,并转到2。{n=V(R),表明期望收到V(R)}

由以上算法可知,对于停止-等待协议,由于每发送一个数据帧就停止并等待,因此用1bit编号就够。在停止-等待协议中,若连续出现相同发送序号的数据帧,表明发送端进行了超时重传。连续出现相同序号的确认帧,表明接收端收到了重复帧。

此外,为了超时重发和判定重复帧的需要,发送方和接受方都需设置一个帧缓冲区。发送端在发送完数据帧时,必须在其发送缓存中保留此数据帧的副本,这样才能在出差错时进行重传。只有在收到对方发来的确认帧ACK时,方可清除此副本。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2016年09月05日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档