http://timyang.net/architecture/communication-code-review/ Tim's blog, 关于后端架构、互联网技术、分布式、大型网络应用、NoSQL、Key Value等 Fri, 30 Jul 2010 12:46:50 +0000 http://wordpress.org/?v=2.9.1 hourly 1 http://timyang.net/architecture/communication-code-review/comment-page-1/#comment-1346 edisonxp Fri, 28 Aug 2009 08:15:07 +0000 http://timyang.net/?p=207#comment-1346 大规模集群系统中，完美的方案是引入一个类似google chubby的paxos仲裁组件来充当配置系统. 节点的增/删都会由仲裁组件发现并callback通知到调用方. 大规模集群系统中，完美的方案是引入一个类似google chubby的paxos仲裁组件来充当配置系统.
节点的增/删都会由仲裁组件发现并callback通知到调用方.

]]> http://timyang.net/architecture/communication-code-review/comment-page-1/#comment-534 Davidfan Fri, 22 May 2009 07:01:59 +0000 http://timyang.net/?p=207#comment-534 楼主的重发逻辑感觉是把UDP网络层做的工作加到TCP上，这样严格的重发会导致许多问题(接收发对数据包的确认，发送方对确认包的接收，接收方的处理速度，接收方对收到重复包的处理，发送发ttl_X的时间设置，等等都需要根据实际情况调整)，总之，搞起来很麻烦，而且实现后会不断有问题要进行调整 楼主的重发逻辑感觉是把UDP网络层做的工作加到TCP上，这样严格的重发会导致许多问题(接收发对数据包的确认，发送方对确认包的接收，接收方的处理速度，接收方对收到重复包的处理，发送发ttl_X的时间设置，等等都需要根据实际情况调整)，总之，搞起来很麻烦，而且实现后会不断有问题要进行调整

]]> http://timyang.net/architecture/communication-code-review/comment-page-1/#comment-533 tangfl Fri, 22 May 2009 02:04:01 +0000 http://timyang.net/?p=207#comment-533 在上千个节点的场合，节点故障就不会是“很少”了。 所以，是否要实现额外的复杂度，还是取决于目标的规模 在上千个节点的场合，节点故障就不会是“很少”了。
所以，是否要实现额外的复杂度，还是取决于目标的规模

]]>