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

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

每个客户机发送自己的多播消息以搜索服务器，然后服务器响应该消息。客户端可以定期（在服务器停机的情况下）重复发送此多播消息，直到服务器响应

服务器定期发送多播消息信标。客户端订阅多播组，并以这种方式接收服务器的多播消息并完成发现

在1。如果有许多客户机，那么最初会传输许多多播消息（每个客户机一条）。只有服务器才能订阅和接收来自客户端的多播消息。一旦服务器响应了客户端，客户端就停止发送多播消息。一旦所有客户端完成了对服务器的发现，就不会在网络上传输更多的多播消息。但是，如果服务器关闭，则每个客户端都会每隔一段时间发送一个多播消息信标，直到服务器备份并能够响应为止

在2。只有服务器会定期提交多播消息信标。此消息最终将路由到订阅了多播组的所有客户端。一旦客户端接收到数据包，客户端的UDP侦听套接字就会关闭，并且不再订阅多播组。但是，服务器必须继续发送多播信标，以便新的客户端可以发现它。它将继续定期发送信标，而不管是否有客户机需要查找

所以，我看到了这两种方法的利弊。在我看来#1最初会导致更重的负载，但这个负载最终会降低到零。在#2中，服务器将永远继续发送信标

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

我建议使用方法2，因为很可能（取决于应用程序）您的客户机会比服务器多得多。通过让服务器发送一个信标，您只需每隔一段时间发送一个数据包，而不是为每个客户机发送一个数据包

---

这种方法的另一个好处是，它使客户机更容易确定新服务器何时可用，或现有服务器何时离开网络，因为他们不必维护与每台服务器的连接，也不必不断轮询每台服务器来找出答案。

这两种方法同样可行

方法#1的论点是，在正常原则下，客户端启动请求，服务器监听并响应请求

方法#2的论点是，多播的目的是让一个主机可以发送一个数据包，并且它可以被多个客户端（一对多）接收，因此它与#1相反

好的，当我想到这一点时，我实际上被吸引到了#2，服务器启动的信标。#1的问题是，假设客户端广播信标，它们与服务器连接，但服务器脱机或更改其IP地址

当服务器备份并发送其第一个信标时，将同时通知所有客户端重新连接，并且您的整个系统将立即备份。使用#1，所有客户机都必须单独意识到服务器不在了，并且都会同时开始多播，直到与服务器重新连接。如果您有1000个客户端和1台服务器，那么您的网络负载将比方法2大1000倍

我知道这些消息很可能很小，一次1000个数据包对UDP网络来说算不了什么，但从设计角度来看，2感觉更好

编辑：我觉得我在发展分裂型人格障碍，但我想到了一个强有力的观点，为什么#1会是一种优势。。。如果您曾经想在多台服务器上实现某种自然的负载平衡或扩展，design#1非常适合这一点。这样，第一个“可用”服务器可以响应客户端的信标并连接到它，而不是所有客户端都跳转到信标服务器的#2。

您的选项#2有一个很大的限制，因为它假设服务器或多或少可以与每个可能的客户端直接通信。根据操作系统的确切网络体系结构，情况可能并非如此。例如，您可能依赖于所有路由器和VPN软件、WAN和NAT以及人们连接网络的任何其他东西，实际上都可以处理多播信标数据包

对于#1，您假设客户端可以向服务器发送UDP数据包。这是一个完全合理的期望，特别是考虑到客户端接下来要做的事情是与同一服务器建立TCP连接

如果服务器宕机，客户机想知道它何时备份，请务必使用，否则总有一天你会因数据包风暴而导致网络崩溃

我在过去几次使用过选项2。它适用于简单的网络拓扑。当UDP数据报超过以太网MTU导致大量碎片时，我们确实看到了一些吞吐量问题。我们所看到的最大问题是，由于许多路由器被配置为阻止多播流量，因此多播发现在更大的拓扑中出现故障

这是拉思