1
This commit is contained in:
@@ -4,10 +4,12 @@ NORM组播技术讨论记录:
|
|||||||
##
|
##
|
||||||
2、可靠组播主要的设计思路:
|
2、可靠组播主要的设计思路:
|
||||||
做到消息传递的不丢包、不错包、不乱序。在消息传递过程中要做到数据处理的一致性,以及系统反演的一致性。
|
做到消息传递的不丢包、不错包、不乱序。在消息传递过程中要做到数据处理的一致性,以及系统反演的一致性。
|
||||||
1. 基于丢包,应该使用何种方式进行重传(TCP?)修复。
|
|
||||||
2. 在拥塞控制、可靠性扩展方面,要控制性能,控制代码量。
|
1. 基于丢包,应该使用何种方式进行重传(TCP?)修复。
|
||||||
3. 组播单个丢包的处理是协议层解决;但组播接收方断连、心跳丢失等问题应该由应用层解决。应用层利用探活、心跳、收发包计数等机制,及时判断发送方的状态。
|
2. 在拥塞控制、可靠性扩展方面,要控制性能,控制代码量。
|
||||||
4. 整体的设计思路是基于UDP,开发所必要的TCP控制功能,剥离冗余部分。
|
3. 组播单个丢包的处理是协议层解决;但组播接收方断连、心跳丢失等问题应该由应用层解决。应用层利用探活、心跳、收发包计数等机制,及时判断发送方的状态。
|
||||||
|
4. 整体的设计思路是基于UDP,开发所必要的TCP控制功能,剥离冗余部分。
|
||||||
|
|
||||||
##
|
##
|
||||||
3、可靠组播的使用场景基于交易系统数据流分析,应该包括总线到模块(主备点)、总线到外部。
|
3、可靠组播的使用场景基于交易系统数据流分析,应该包括总线到模块(主备点)、总线到外部。
|
||||||
##
|
##
|
||||||
|
|||||||
Reference in New Issue
Block a user