UDP广播用于自动搜索服务器
我正在制作一款多人网络游戏。现在要连接到服务器，客户端需要服务器的 IP 地址。
所以，我的实现方式如下。
客户端在广播 IP 和端口 A 上广播其 IP 地址。 服务器通过 A 监听它，
服务器与客户端创建一个新的 UDP 连接，该连接的行为就像客户端通过端口 B 所说的那样。它发送游戏所需的所有重要信息，包括其 IP。
客户端是此连接的服务器，通过端口 B 接收来自服务器的数据。
现在，A 和 B 是常量。因此，当我需要服务器在不同线程中侦听多个客户端时，我可以将线程的差异值放入 A 和 B，但在客户端文件中 A 和 B 独立于这些线程。所以它给了我一个错误：
bind：地址已在使用中
这个问题的合理解决方案是什么？
I am making a multiplayer networking game. Now to connect to the server, client needs the ip address of the server.
So, the way I implement this is as follows.
Client Broadcasts its ip address at Broadcast IP and a port say A.
Server listens to it over A, and
Server creates a new UDP connection with the client behaving as a client say over port B. It sends all the important information required for the game including its IP.
Client is the server for this connection and receives the data from server over port B.
Now, A and B are constants. So when I need the server to listen for multiple clients in different threads I can put diff values to A and B for the threads but in the client file A and B are independent of these threads. So it gives me an error of
bind: Address already in use
What is the plausible solution for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，让客户端广播其地址听起来非常可怕，至少对我来说是这样。广播意味着它只有在服务器位于本地子网上时才能工作，并且会用大量不必要的流量污染网络。
我会让客户端通过 DNS 服务发现 (DNS-SD) 找到服务器。这样做的好处是，只要您的服务器位于本地子网上，您就可以使用多播 DNS，并转换到使用正常管理的 DNS 的广域服务器，根本不需要对客户端进行任何更改。
其次，服务器不应该为每个客户端分配一个线程。虽然这个模型可以在某种程度上发挥作用，但它的开销很大，而且扩展性很差。
最后，对于（我认为是）您最初的问题：我不会为每个客户端使用不同的端口，而是为所有客户端提供一个端口。来自客户端的每个请求都将携带足够的信息，以便服务器执行它包含的任何请求。服务器仅侦听其单个端口，并在每个请求到达时为其提供服务。您可能会为此专用多个线程，但它应该是一个通用线程池——即，所涉及的线程数量只是一个配置问题，对整体设计没有任何逻辑含义（即，特定线程的身份）线程没有任何意义——如果您迁移到具有 8 倍核的更大服务器，添加更多线程只是配置更多线程的简单问题，而不是改变整体设计）。
First of all, having the client broadcast its address sounds pretty horrible, at least to me. Broadcasting means that it'll only work if the server is on the local subnet, as well as polluting the network with a lot of unnecessary traffic.
I'd have the client find the server via DNS Service Discovery (DNS-SD). This has the advantage that you can use multicast DNS as long as your server is on the local subnet, and transition to a wide-area server using normal administered DNS, without making any changes to the client at all.
Second, the server should not dedicate a thread to each client. While this model can be made to work to some degree, it has quite a bit of overhead and scales really poorly.
Finally, to (what I think was) your original question: instead of a different port for each client, I'd have one port for all clients. Each request from a client will carry enough information for the server to carry out whatever request it contains. The server simply listens on its single port, and services each request as it arrives. You might dedicate more than one thread to this, but it should be a generic thread pool -- i.e., the number of threads involved is simply a matter of configuration, with no logical implication to the overall design (i.e., the identity of a particular thread has no significance -- if you move to a bigger server with 8 times as man cores, adding more threads is a simple matter of configuring more threads, not changing the overall design).