zoukankan      html  css  js  c++  java
  • 停止等待协议问题

    1.在停止等待协议中,如果收到重复的报文段时不予理睬(即悄悄地丢弃它,而其他什么也不做)是否可以?试着举出具体例子说一下你的理解与看法?

     哈哈,绝对不可行的呀 ~。

    我们来看一看下面这个图:

     

    A 发送报文段 M1,B 收到后发送确认,但这个确认丢失了。  

    A 发送报文段 M1,B 收到后不予理解。这就导致 A 再次超时重传报文段 M1。

    B 收到重复的报文段都不予理睬,A 就一直超时重传报文段 M1,将会导致 A 的资源浪费呀 ~ 。

    可见,如果收到重复的报文段时不予理睬是不行的。

    2.在停止等待协议中,如果不使用编号是否可行?请说下你的理由?

    不使用编号是不可以的。我们可以看看下面这个图:

     如果在 A 发送报文段 M1,B 收到后发送确认(无编号),这个确认很晚才送到 A。

    这样 A 就没法在规定时间等待确认,认为发送的报文段在 B 没收到,启动超时重传机制,重新发送报文段 M1。

    在一段时间后,B 发送的第一个确认到达了 A,于是 A 发送下一个报文段 M2,但 M2 丢失了。

    B 收到 A发送的重传 M1.但 B 并不知道是重传中,因为报文段没有编号。 B 是无法判断报文段属于重传的报文段,还是

    最新的报文段。 B 这样只能收下重新传过来的报文段,并发送确认给 A。这样会让 A 误以为是对 M2 报文段的确认,认为发送的两个报文段都已经到达B。

    哈哈,我们是不是可以看出来问题了呀~,如果不使用编号的话,接收方是不清楚收到的报文段有没有重复类别。

    3.假定在传输层使用停止等待协议。发送方在发送报文段M0后设定的时间内未收到确认,于是重传M0,但M0又迟迟不能到达接收方。不久,发送方收到了迟到的对M0的确认,于是发送下一个报文段M1,不久就收到了对M1的确认。接着发送方发送新的报文段M0,但这个新的M0在传送的过程中丢失了。正巧,一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨出M0是旧的。于是就收下M0,并发送确认。显然,接收方后来收到的M0是重复的,协议失败了。

    你可以画下双方交换报文段的过程吗?

    从上面的图我们可以看到,接收方在第二次的时候把超时的 M0 当成了新的 M0,。(无法判断 M0 是否为发送方发送的最新报文段) 

     参考:谢希仁老师的《计算机网络第七版》~

  • 相关阅读:
    电信的星空极速客户端软件强制安装策略升级了
    CSS 控件适配器工具包对事件处理的 Bug 以及修正办法
    IronPython 源码剖析系列(1):IronPython 编译器
    对 CSS 控件适配器处理事件的 Bug 进一步修正
    明天去长春出差。。。
    Windows 系统右键菜单假死问题解决一例
    使用 Anthem.NET 的常见回调(Callback)处理方式小结
    TreeViewVisitor: 一个快捷访问 TreeView 控件节点的帮助类
    ASP.NET Web开发框架之六 数据库文档方法,工具和实践
    推荐功能强大的ORM Profiler,ORM问题追踪的利器
  • 原文地址:https://www.cnblogs.com/xiaowei123/p/13143884.html
Copyright © 2011-2022 走看看