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

Question

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

1. 每个客户端在搜索服务器，然后服务器响应的发出自己的多播消息。客户端可以定期重复发送此多播消息（在服务器关闭的情况下），直到服务器响应。
2. 服务器定期发送一个多播消息信标。客户端订阅多播组并以这种方式接收服务器的多播消息并完成发现。

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

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

所以，我看到优点和缺点。在我看来＃1最初会导致更重的负载，但是这个负载最终减少到零。在＃2服务器将继续发送一个灯塔永远。

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

Answer 1

我会推荐方法＃2，因为它很可能（取决于应用程序）您将拥有比您将服务器更多的客户端。通过让服务器发送信标，您每隔一段时间只发送一个数据包，而不是为每个客户端发送一个数据包。

此方法的另一个好处是，它使客户端更容易确定新服务器何时变为可用，或者当现有服务器离开网络时，因为它们不必与每个服务器保持连接服务器，或保持轮询每个服务器，找出。

Answer 2

两者都是同样可行的方法。

方法＃1的参数是在正常的原则下，客户端发起请求，服务器监听并响应它们。

方法＃2的参数是多点传送的意义在于，一个主机可以发送一个数据包，它可以被许多客户端（一对多）接收，所以它的意思是＃1。

好的，正如我想到的那样，我实际上被抽象为＃2，服务器启动的信标。 ＃1的问题是让我们说客户端广播信标，并且他们与服务器连接，但是服务器要么脱机，要么改变它的IP地址。

当服务器备份并发送其第一个信标时，将同时通知所有客户端重新连接，并且您的整个系统立即备份。通过＃1，所有的客户端将不得不单独认识到服务器已经消失，并且他们都将同时开始组播，直到与服务器连接为止。如果你有1000个客户端和1个服务器，你的网络负载就会比方法＃2大1000倍。

我知道这些消息很可能很小，每次1000个数据包对于UDP网络来说没有任何意义，但从设计的角度来看，＃2感觉更好。

编辑︰我觉得我在这里发展分裂人格障碍，但只是想到了为什么＃1会是一个优势的强大点......如果你想实施某种自然负载平衡或使用多台服务器进行扩展，设计＃1适用于此。这样，第一个“可用”服务器可以响应客户端的信标并连接到它，而＃2则是所有客户端都跳转到信标服务器的。

Answer 3

您的选项＃2有一个很大的限制，因为它假设服务器可以或多或少地直接与每个可能的客户端进行通信。根据运营系统的确切网络架构，情况可能并非如此。例如，您可能会认为所有路由器和VPN软件以及WAN和NAT以及人们将网络连接在一起的任何其他事物都可以实际处理多播信标数据包。

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

如果服务器出现故障，而且客户希望找出时，它的备份，是一定使用exponential backoff否则你将采取网络打倒一个数据包风暴一天！

Answer 4

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

当你设计你的协议套件时，issue that Greg alluded to是非常重要的。只要您超越简单的网络拓扑，就必须找到address translation,IP spoofing的解决方案，以及与从发现层到通信层的越区切换有关的其他一系列问题。他们中的大多数都必须专门针对您的服务器如何识别自己，并确保识别是客户可以使用的。如果我可以再做一次（我们说过多少次），我会寻找基于标准的发现机制，以适应账单并开始解决其他协议套件问题。你真正想要做的最后一件事是提出一个非常好的发现方案，由于一些不可预见的网络拓扑结构，在部署完成后的一周内就会打破。 Google service discovery作为首发名单。我个人倾向于DNS-SD，但有很多其他选项可用。