首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >TCP keep-alive的可扩展性

TCP keep-alive的可扩展性
EN

Stack Overflow用户
提问于 2009-06-03 17:02:03
回答 3查看 1.3K关注 0票数 0

考虑由各种设备组成的大规模异构网络。这些设备以点对点的方式向网络上的其他设备提供服务。用于跟踪所有节点上的服务可用性的机制当前使用被标记为保持活动的TCP套接字,通常是在节点在线期间。这导致每个节点具有与每个其他节点(在对等基础设施的子网内)开放的套接字。

我的替代方法是使用发布/订阅模型,其中节点在新服务变得可用时将它们推送到网络,并且它们的对等节点在它们想要订阅服务时对它们进行缓存。这听起来可行吗?

EN

回答 3

Stack Overflow用户

发布于 2009-06-03 17:25:55

我从你写的东西中理解到,交流是严格的点对点的,有相当长的持续时间(‘租约’)。如果这不是真的,那么是的,你应该(可以)改变网络模型以匹配通信,你的想法听起来很合理。

关于您的第二个问题,由于TCP套接字和keep-alive只是一个概念,因此不存在(或者说非常小的)具有这种keep-alive契约的固有成本。在实践中,YMMV是因为不同的套接字实现需要不同的资源,并且可能需要其他操作来保持通道打开。然而,有许多实现只需要很少的资源就可以打开套接字(例如,select()-type)。

如果有许多相同类型的服务的实现者,并且您不能(或不想)静态地预测它们将出现在何处,则发现服务(服务的发布/订阅)最有意义。

简而言之,我想说的是,只有当你拥有的通信类型不适合当前的架构时,你才应该改变设计。您的想法听起来当然非常可行,但更多关于通信模式的信息将是必要的,以便对结果进行估计。

票数 1
EN

Stack Overflow用户

发布于 2009-06-03 17:10:39

是的,对于任何P2P网络来说,使用keep alive似乎都不是一个好主意。我不仅让连接在数据传输期间保持打开状态,还会在不同的套接字上完全保持节点状态更新,以便不会干扰文件传输。

票数 0
EN

Stack Overflow用户

发布于 2009-06-03 17:43:47

如果您的TCP Keep Alive机制仅用于跟踪服务可用性(这意味着您从不跨这些连接传递服务请求/响应),则使用TCP套接字肯定是过度杀伤力。TCP套接字确实占用大量资源。

一种更具伸缩性的方法是使用发布/订阅模型,该模型以固定的时间间隔使用UDP发布消息来通告服务的持续存在。您还可以使用从断开连接的节点发布的服务关闭消息来优雅地声明服务的结束。

更进一步,如果您想要在真正大规模的网络中获得最优,并且准备投入一些时间和精力--考虑像DHT这样的结构化P2P机制。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/945868

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档