sockets - UDP 服务器发现 - 客户端应该发送多播以查找服务器还是服务器应该发送常规信标？

Question

我有需要全部连接到单个服务器进程的客户端。我正在为客户端使用 UDP 发现来查找服务器。我让客户端和服务器交换IP地址和端口号，以便在发现完成后建立TCP/IP连接。这样，数据包的大小就可以保持很小。我看到这可以使用 UDP 以两种方式之一完成:

每个客户端发送自己的多播消息以搜索服务器，然后服务器对其进行响应。客户端可以定期(在服务器关闭的情况下)重复发送此多播消息，直到服务器响应。

服务器定期发送多播消息信标。客户端订阅多播组，从而接收到服务器的多播消息并完成发现。

1. 如果有很多客户端，那么最初会传输许多多播消息(每个客户端一个)。只有服务器会订阅和接收来自客户端的多播消息。一旦服务器响应客户端，客户端停止发送多播消息。一旦所有客户端都完成了对服务器的发现，就不会再在网络上传输多播消息。但是，如果服务器已关闭，则每个客户端将间隔发送多播消息信标，直到服务器备份并可以响应。

2. 只有服务器会定期提交多播消息信标。该消息最终会被路由到订阅多播组的所有客户端。一旦客户端收到数据包，客户端的 UDP 监听套接字就会关闭，并且它们不再订阅多播组。但是，服务器必须继续发送多播信标，以便新客户端可以发现它。它会继续定期发送信标，无论是否有任何客户端需要发现。

所以，无论哪种方式，我都看到了利弊。在我看来，#1 最初会导致更重的负载，但这个负载最终会减少到零。在＃2中，服务器将永远继续发送信标。

UDP 和多播对我来说是一个相当新的话题，所以我有兴趣找出哪种方法是首选方法，哪种方法可以减少网络负载。

Answer 1

我过去几次使用过选项＃2。它适用于简单的网络拓扑。当 UDP 数据报超过以太网 MTU 导致大量碎片时，我们确实看到了一些吞吐量问题。我们看到的最大问题是，由于许多路由器被配置为阻止多播流量，因此多播发现在较大的拓扑中会失效。
issue that Greg alluded to在设计协议(protocol)套件时要考虑非常重要。一旦您超越了简单的网络拓扑，您就必须为 address translation 找到解决方案。 , IP spoofing ，以及与从发现层到通信层的切换相关的大量其他问题。它们中的大多数都与您的服务器如何标识自己以及确保标识是客户端可以使用的东西有关。
如果我可以再做一次(我们说过多少次这个短语)，我会寻找符合要求的基于标准的发现机制并开始解决其他协议(protocol)套件问题。您真正想做的最后一件事是提出一个非常好的发现方案，该方案在您部署它后的一周内因某些不可预见的网络拓扑而中断。谷歌 service discovery 为起始名单。我个人倾向于DNS-SD但还有很多其他选择。