TCP keep-alive 的可扩展性
考虑各种设备的大规模异构网络。 这些设备以点对点的方式向网络上的其他设备提供服务。 用于跟踪所有节点的服务可用性的机制当前使用标记为保持活动的 TCP 套接字，通常在节点在线期间。 这导致每个节点都有一个与每个其他节点（在对等基础设施的子网内）打开的套接字。
关于以这种方式使用 TCP keep-alive 的可扩展性，存在哪些争论？
我的替代方法是使用发布/订阅模型，其中节点在新服务可用时将其推送到网络，而它们的对等节点会在它们想要订阅服务时缓存它们。 这听起来可行吗？
Consider a large scale, heterogeneous network of various devices. These devices are providing services to others on the network in a peer-to-peer fashion. The mechanism used to track service availabilty across all nodes is currently using TCP sockets marked as keep-alive, usually for the duration the node is online. This leads to every node having a socket open with every other node (within a subnet of the peer-to-peer infrastructure).
What arguments exist regarding the scaleability of using TCP keep-alive in this way?
My alternative approach is to use a publish/subscribe model, where nodes push new services to the network as they become available, and their peers cache them for when they want to subscribe to a service. Does this sound feasable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，对于任何 P2P 网络来说，使用保持活动似乎都是一个坏主意。 我不仅会在传输数据时保持连接打开，而且还会在不同的套接字上保持节点状态更新，以免干扰文件传输。
Yeah using keep alive seems like a bad idea for any P2P network. Not only would I only have connections kept open while data is being transferred I would also keep node state updates on a different sockets altogether so as to not interfere with file transmissions.
如果您的 TCP Keep Alive 机制仅用于跟踪服务可用性（这意味着您从不通过这些连接通信服务请求/响应），那么使用 TCP 套接字绝对是一种过度的杀伤力。 TCP 套接字确实占用大量资源。
一种更具可扩展性的方法可以是使用发布/订阅模型，该模型定期使用 UDP 发布消息来通告服务的持续存在。 您还可以使用从断开连接的节点发布的服务关闭消息来优雅地声明服务结束。
更进一步，如果您打算在真正大规模的网络中获得最佳效果，并且准备好投入一些时间和精力，请考虑采用结构化 P2P 机制，例如 DHT。
If your TCP Keep Alive mechanism is being used only for tracking service availability (meaning, you never communicate service request/response across these connections), the use of TCP sockets is definitely an over kill. TCP sockets do take significant resources.
A more scalable method could be using a publish/subscribe model that uses UDP publish messages at regular intervals to advertise continued existence of the service. You could also use a service-down message published from a disconnecting node to gracefully declare end of service.
Going further, if you mean to get optimal with really large scale networks and, are ready to put in some time and effort -- consider a structured P2P mechanism like DHT.
我从你所写的内容中解释说，通信是严格点对点的，具有相当长的持续时间（“租约”）。 如果这是真的，则意味着您在发布-订阅模型中将一无所获。 如果这不是真的，那么是的，您应该（可以）更改网络模型以匹配通信，并且您的想法听起来不错。
关于你的第二个问题，由于 TCP 套接字和保持活动只是一个概念，因此拥有这样的保持活动合同没有（或非常小的）内在成本。 在实践中，YMMV 由于不同的套接字实现需要不同的资源，并且可能需要其他操作来保持通道打开。 然而，有许多实现只需要很少的资源来打开套接字（例如 select() 类型）。
如果同一类型的服务有许多实现者，并且您无法（或不想）静态预测它们将出现在哪里，则发现服务（服务的发布/订阅）最有意义。
简而言之，我想说，只有当您所拥有的通信类型非常适合当前架构时，您才应该更改设计。 您的想法听起来当然非常可行，但是需要更多有关通信模式的信息才能对结果进行估计。
I interpret from what you wrote that the communication is strictly point-to-point, with considerable duration ('leases'). If this is true, it means that you will gain nothing in a publish-subscribe model. If this is not true, then yes, you should (could) change the network model to match the communications, and your idea sounds sound.
Regarding your second question, since TCP sockets and keep-alive is just a concept, there is no (or a very small) intrinsic cost of having such a keep-alive contract. In practice YMMV since different socket implementations require different resources, and other actions might be required to keep the channel open. There are however many implementations which require very little resources for open sockets (select()-type for example).
A discovery service (publish/subscribe of services) makes most sense if there are many implementers of the same type of service, and you cannot (or do not want to) predict statically where they will appear.
In short, I would say that you should only change the design if the type of communication that you have fits the current architecture badly. Your idea certainly sounds very feasible, but more information about the communication patterns would be necessary to make an estimation of the outcome.