考虑各种设备的大规模异构网络。这些设备以点对点的方式向网络上的其他人提供服务。用于跨所有节点跟踪服务可用性的机制当前使用标记为保持活动的 TCP 套接字，通常在节点在线期间。这导致每个节点都有一个与所有其他节点（在对等基础设施的子网内）打开的套接字。
关于以这种方式使用 TCP keep-alive 的可扩展性存在哪些争论？
我的替代方法是使用发布/订阅模型，其中节点在新服务可用时将它们推送到网络，并且它们的对等点会在它们想要订阅服务时缓存它们。这听起来可行吗？
【问题讨论】：
标签： sockets tcp scalability p2p keep-alive
我从您所写的内容中了解到，通信是严格的点对点的，具有相当长的持续时间（“租约”）。如果这是真的，则意味着您在发布-订阅模型中将一无所获。如果这不是真的，那么是的，您应该（可以）更改网络模型以匹配通信，并且您的想法听起来不错。
关于您的第二个问题，由于 TCP 套接字和 keep-alive 只是一个概念，因此拥有这样的 keep-alive 合同没有（或非常小的）内在成本。在实践中 YMMV 因为不同的套接字实现需要不同的资源，并且可能需要其他操作来保持通道打开。然而，有许多实现需要很少的资源来打开套接字（例如 select() 类型）。
如果有许多相同类型的服务的实现者，并且您不能（或不想）静态预测它们将出现在哪里，则发现服务（服务的发布/订阅）最有意义。
简而言之，我会说，只有在您的通信类型与当前架构不匹配时，您才应该更改设计。您的想法听起来确实很可行，但需要更多有关通信模式的信息来估计结果。
【讨论】：
是的，对于任何 P2P 网络来说，使用 keep alive 似乎都是个坏主意。我不仅会在数据传输时保持连接保持打开状态，而且还会在不同的套接字上保持节点状态更新，以免干扰文件传输。
【讨论】：
如果您的 TCP Keep Alive 机制仅用于跟踪服务可用性（这意味着您永远不会在这些连接之间传递服务请求/响应），那么使用 TCP 套接字绝对是一种过度杀戮。 TCP 套接字确实会占用大量资源。
一种更具可扩展性的方法是使用发布/订阅模型，该模型使用 UDP 定期发布消息来宣传服务的持续存在。您还可以使用从断开连接的节点发布的服务停止消息来优雅地声明服务结束。
更进一步，如果您想通过真正大规模的网络达到最佳状态，并且准备投入一些时间和精力，请考虑使用结构化 P2P 机制，例如 DHT。
【讨论】：