代码之家 › 专栏 › 技术社区 › Elan

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

discovery multicast udp sockets

8

Elan · 技术社区 · 17 年前

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

每个客户机发送自己的多播消息以搜索服务器,然后服务器会对其做出响应。客户端可以定期(在服务器关闭的情况下)重复发送此多播消息,直到服务器做出响应。
服务器定期发送多播消息信标。客户端订阅多播组,并以这种方式接收服务器的多播消息并完成发现。

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

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

所以,我看正反两面。在我看来,一开始#1会导致更重的负荷,但这个负荷最终会降为零。在#2中,服务器将永远继续发送信标。

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

4 回复 | 直到 17 年前

1

4

Community Mohan Dere 9 年前

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

这个 issue that Greg alluded to 在设计协议套件时要考虑到这一点。一旦你超越了简单的网络拓扑,你就必须找到解决方案 address translation , IP spoofing ,以及与从发现层到通信层的切换相关的大量其他问题。其中大多数都与服务器如何识别自身以及确保客户机可以使用标识有关。

如果我能再做一遍(我们说了多少次这个短语),我会寻找符合法案的基于标准的发现机制,并开始解决其他协议套件问题。最后一件你真正想做的事是想出一个非常好的发现方案,因为一些不可预见的网络拓扑结构,在你部署后的一周内就可以完成。谷歌 service discovery 一个开始的名单。我个人倾向于 DNS-SD 但是还有很多其他的选择。

2

X-Cubed 17 年前

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

该方法的另一个好处是,它使得客户端更容易确定何时可以获得新服务器,或者当现有服务器离开网络时,因为它们不必维护到每个服务器的连接,或者保持轮询每个服务器,以找出。

3

1

Brandon 17 年前

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

方法1的论点是,通常情况下,客户机发起请求,服务器监听并响应请求。

方法2的论点是,多播的目的是让一个主机可以发送一个数据包,并且它可以被许多客户端(一对多)接收,所以它应该与1相反。

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

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

我知道这些消息很可能很小,一次1000个数据包对UDP网络来说毫无意义,但是从设计的角度来看2感觉更好。

编辑: 我觉得我正在发展一种分裂的人格障碍,但只是想了一个强大的点,为什么1将是一个优势。。。如果您曾经想要实现某种自然的负载平衡或在多个服务器上扩展,那么design#1可以很好地实现这一点。这样,第一个“可用”服务器就可以响应客户机的信标并连接到它,而不是所有客户机都跳到信标服务器的#2。

4

1

Greg Hewgill 17 年前

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

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

如果服务器坏了,客户想知道什么时候备份,那么当然使用 exponential backoff 否则总有一天你会因为一场数据包风暴而摧毁网络!