我的客户端需要连接到单个服务器进程 . 我正在使用UDP发现为客户端找到服务器 . 我有客户端和服务器交换IP地址和端口号，以便在完成发现后 Build TCP / IP连接 . 这样，数据包大小保持很小 . 我看到这可以使用UDP以两种方式之一完成：
-
每个客户端发出自己的多播消息以搜索服务器，然后服务器响应该服务器 . 客户端可以定期重复发送此多播消息（在服务器关闭的情况下），直到服务器响应 .
-
服务器定期发送多播消息信标 . 客户端订阅多播组，并以这种方式接收服务器的多播消息并完成发现 .
在1.如果有许多客户端，那么最初将传输许多多播消息（每个客户端一个） . 只有服务器才会订阅并从客户端接收多播消息 . 一旦服务器响应客户端，客户端就不再发送多播消息 . 一旦所有客户端完成了对服务器的发现，就不会在网络上传输进一步的多播消息 . 但是，如果服务器关闭，则每个客户端将间隔发送多播消息信标，直到服务器备份并且可以响应 .
在2.只有服务器会定期提交多播消息信标 . 此消息最终将路由到订阅多播组的所有客户端 . 客户端收到数据包后，客户端的UDP侦听套接字将关闭，并且不再订阅多播组 . 但是，服务器必须继续发送多播信标，以便新客户端可以发现它 . 它将继续定期发送信标，无论是否有任何客户端需要发现它们 .
所以，无论如何，我都看到了利弊 . 在我看来，＃1最初会导致更重的负载，但这个负载最终会降低到零 . 在＃2中，服务器将继续永远发送信标 .
UDP和多播对我来说是一个相当新的话题，所以我有兴趣找出哪种方法是首选方法，哪种方法可以减少网络负载 .
4 回答
我过去曾多次使用选项＃2 . 它适用于简单的网络拓扑 . 当UDP数据报超过以太网MTU时，我们确实看到了一些吞吐量问题，导致大量碎片 . 我们看到的最大问题是，由于许多路由器被配置为阻止多播流量，因此多播发现在较大的拓扑中发生故障 .
在设计协议套件时，issue that Greg alluded to非常重要 . 一旦超越简单的网络拓扑，就必须找到address translation，IP spoofing的解决方案，以及与发现层到通信层的切换相关的许多其他问题 . 他们中的大多数都必须专门针对您的服务器如何识别自身并确保识别是客户可以使用的内容 .
如果我能再做一遍（我们说了多少次这个短语），我会寻找适合该法案并开始解决其他协议套件问题的基于标准的发现机制 . 你真正想要做的最后一件事是提出一个非常好的发现方案，由于一些无法预料的网络拓扑结构，它在部署之后打破了一周 . Google service discovery作为首发列表 . 我个人倾向于DNS-SD但是还有很多其他选择 .
我建议方法＃2，因为它可能（取决于应用程序）你将拥有比服务器更多的客户端 . 通过让服务器发送信标，您只需每隔一段时间发送一个数据包，而不是每个客户端发送一个数据包 .
此方法的另一个好处是，它使客户端更容易确定新服务器何时可用，或者现有服务器何时离开网络，因为它们不必维护与每个服务器的连接，或保持轮询每个服务器，找出答案 .
两者都是同样可行的方法 .
方法＃1的论点是，通常原则上，客户端发起请求，服务器监听并响应它们 .
方法＃2的论点是多播点是这样的，一个主机可以发送一个数据包，并且它可以被许多客户端（一对多）接收，所以它意味着与＃1相反 .
好吧，正如我想到的那样，我实际上已经被＃2，服务器发起的信标所吸引 . ＃1的问题是让我们说客户端广播信标，他们与服务器连接，但服务器要么脱机或更改其IP地址 .
当服务器备份并发送其第一个信标时，将同时通知所有客户端重新连接，并立即备份整个系统 . 对于＃1，所有客户端都必须单独意识到服务器已经消失，并且它们将同时开始多播，直到与服务器连接 . 如果你有1000个客户端和1个服务器，你的网络负载实际上比方法＃2大1000倍 .
我知道这些消息很可能很小，一次只有1000个数据包对UDP网络没有任何意义，但从设计的角度来看，＃2感觉更好 .
Edit: 我觉得我是'm developing a split-personality disorder here, but just thought of a powerful point of why #1 would be an advantage... If you ever wanted to implement some sort of natural load balancing or scaling with multiple servers, design #1 works well for this. That way the first 902056 server can respond to the client'的信标并连接到它，而不是＃2所有客户端都跳转到信标服务器 .
您的选项＃2有一个很大的限制，它假定服务器可以或多或少地直接与每个可能的客户端进行通信 . 根据您的操作系统的确切网络架构，情况可能并非如此 . 例如，您可能依赖于所有路由器和VPN软件以及WAN和NAT以及人们将网络连接在一起的任何其他内容，实际上可以处理多播信标数据包 .
使用＃1，您假设客户端可以向服务器发送UDP数据包 . 这是一个完全合理的期望，特别是考虑到客户端将要做的下一件事就是 Build 到同一服务器的TCP连接 .
如果服务器出现故障并且客户端想要查找它何时备份，请务必使用exponential backoff否则您将在某天使用数据包风暴来关闭网络！