一个双工模式协商的问题
2014-03-31 22:04
323 查看
两个端口对接时,一端设置为全双工模式,另一端开启自协商,协商结果是全双工还是半双工呢?答案是半双工。
对接双方都开启自协商的情况下,会协商出最优模式。如果只有一端开启自协商,就不能获知对端的双工能力,本端只能自动降级为半双工模式。这种情况下,就出现了一端半双工一端全双工的情况。
遗憾的是,一端半双工一端全双工的情况,并不能很好地工作。半双工模式下,端口检测到链路空闲,于是开始发送数据帧。全双工模式发送数据帧之前,不会检测链路的空闲状态就直接发送。这种情况下,就会发生冲突。如果链路比较忙,会出现大量的冲突。对于TCP业务而言,数据帧发生冲突,意味着重传报文。最糟糕的情况下,业务可能会基本不可用。
IEEE标准不建议端口配置为强制模式。但是,有些机构的以太网部署得比较早,并且端口配置成了强制模式。更不幸的是,这些配置很可能作为模板应用到新部署的网路中。这些机构中,更改配置需要层层审批并评估对现有网络的影响。端口配置为强制模式,一般情况下也没有明显的问题,也就没有动力去改变这些配置。所以,强制模式还是有可能会在实际网络中遇到。
对接双方都开启自协商的情况下,会协商出最优模式。如果只有一端开启自协商,就不能获知对端的双工能力,本端只能自动降级为半双工模式。这种情况下,就出现了一端半双工一端全双工的情况。
遗憾的是,一端半双工一端全双工的情况,并不能很好地工作。半双工模式下,端口检测到链路空闲,于是开始发送数据帧。全双工模式发送数据帧之前,不会检测链路的空闲状态就直接发送。这种情况下,就会发生冲突。如果链路比较忙,会出现大量的冲突。对于TCP业务而言,数据帧发生冲突,意味着重传报文。最糟糕的情况下,业务可能会基本不可用。
IEEE标准不建议端口配置为强制模式。但是,有些机构的以太网部署得比较早,并且端口配置成了强制模式。更不幸的是,这些配置很可能作为模板应用到新部署的网路中。这些机构中,更改配置需要层层审批并评估对现有网络的影响。端口配置为强制模式,一般情况下也没有明显的问题,也就没有动力去改变这些配置。所以,强制模式还是有可能会在实际网络中遇到。
相关文章推荐
- 一个关于10M以太网、双工协商、CRC错误等问题的实践性总结
- 组合还是继承,这是一个问题?——由模式谈面向对象的原则之多用组合、少用继承
- NAPI模式--中断和轮询的折中以及一个负载均衡的问题
- 单例模式之懒汉的并发问题,只需要添加一个 synchronized 就可以解决了
- 关于c++中原型模式的一个问题,请告诉进来帮忙指点一下
- Android Sqlite3 query的一个问题(多语言模式)
- 图像检索服务器编写问题记录——用单例模式确保log类、server类只返回一个实例
- 由一个例子想到对事务脚本模式的问题
- 职责链模式和工厂模式混合求解一个简单的解密问题
- 用Factory设计模式解决一个网友的问题
- [负载均衡案例分享系列] 一个由负载均衡使用模式导致间断访问失败问题的处理
- 组合还是继承,这是一个问题?——由模式谈面向对象的原则之多用组合、少用继承
- 思考一个模式识别与机器学习相关的问题
- iOS数据、界面分开设计模式遇到的一个问题
- 使用wcf的双工模式做的一个控制台聊天app
- 模式匹配(pattern matching)问题:判断一个长为n的字符串X中是否包含常为m的字串Y(m<=n)
- 只有一个公网IP也可以使用LVS的DR模式!(外带php session粘滞问题解决)
- 解析 Java 类和对象的初始化过程 由一个单态模式引出的问题谈起
- 【转】一个非常常见但容易被忽略的c++问题——用IPML模式可以解决
- 关于CS模式下,控制一个容器内控件的值问题