通过socket服务器广播ip:port
我试图找到一种方法让客户端知道套接字服务器 ip:port，而不需要显式定义它。一般来说，我有一个在便携式设备上运行的套接字服务器，它通过 DHCP（通过 WiFi）连接到网络，理想情况下客户端应该能够自动找到它。
所以我想一个问题是套接字服务器是否可以以某种方式通过本地网络广播它的地址？我认为 UPnP 可以做到这一点，但我不想参与其中。
我很确定这个问题在 Stack 上被问过很多次，但我可以找到合适的关键字来搜索它。
I'm trying to find a way for client to know socket server ip:port, without explicitly defining it. Generally I have a socket server running on portable device that's connect to network over DHCP (via WiFi), and ideally clients should be able to find it automaticaly.
So I guess a question is whether socket server can somehow broadcast it's address over local network? I think UPnP can do this, but I'd rather not get into it.
I'm quite sure that this question was asked on Stack lot's of times, but I could find proper keywords to search for it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
实现此目的的一种方法是通过 UDP 广播数据包。如果您使用的是 BSD 套接字，请参阅 beej 指南。 此处是 Microsoft 的相同版本。
假设应用程序的所有客户端都位于路由器的同一侧，则广播地址
255.255.255.255（或 IPv6 的ff02::1）应大于足够的。多播是另一种选择，但如果这是仅限 LAN 的事情，我认为没有必要。
建议
选择一个 UDP 端口号（例如，我们选择 1667）。客户端应侦听
255.255.255.255:1667上的 UDP 消息（或任何等效的消息。例如：IPEndPoint(IPAddress.Any, 1667)）。服务器应在同一地址上广播消息。格式建议
UDP 数据包：前四个字节作为幻数，接下来的四个字节是 IPv4 地址（您可能需要添加其他内容，例如服务器名称）。
幻数是为了防止与使用同一端口的另一个应用程序发生冲突。检查数据包的长度和幻数。
服务器会以大约 30 秒的时间间隔广播该数据包。 （或者，您可以让服务器仅在客户端通过广播发送请求时发送响应。）
One method of doing this is via UDP broadcast packets. See beej's guide if you're using BSD sockets. And here is Microsoft's version of the same.
Assuming all the clients of the application are on the same side of a router then a broadcast address of
255.255.255.255(orff02::1for IPv6) should be more than adequate.Multicast is another option, but if this is a LAN-only thing I don't think that's necessary.
Suggestion
Pick a UDP port number (say for the sake of an example we pick 1667). The client should listen to UDP messages on
255.255.255.255:1667(or whatever the equivalent is. e.g.:IPEndPoint(IPAddress.Any, 1667)). The server should broadcast messages on the same address.Format Suggestion
UDP Packet: First four bytes as a magic number, next four bytes an IPv4 address (and you might want to add other things like a server name).
The magic number is just in case there is a collision with another application using the same port. Check both the length of the packet and the magic number.
Server would broadcast the packet at something like 30 second time intervals. (Alternatively you could have the server send a response only when a client sends a request via broadcast.)
一些选项是：
对于您的情况（WiFi 网络上的客户端），UDP 广播数据包就足够了，它是多平台的，并且从地面实现起来并不太困难向上。
选择此选项，两个主要算法是：
服务器发送“通告”广播数据包，客户端侦听广播地址。一旦客户端收到“announce”数据包，他们就知道服务器地址。现在，他们可以向服务器发送 UDP 数据包（服务器将发现用于发送回复的地址），或使用 TCP 进行连接。
客户端发送“发现”广播数据包，服务器监听广播地址。一旦服务器收到“发现”数据包，它可以直接回复“宣布”UDP 数据包。
其中之一可能更适合您的应用程序，具体取决于情况。
请考虑以下论点：
作为这两个选项的组合，服务器可以在出现时发送“无偿宣布”广播数据包，然后它可以侦听来自客户端的“发现”广播请求，并使用常规 UDP 数据包直接回复其中一个。
从这里，客户端可以根据需要继续：使用 UDP 向服务器发送直接请求，连接到“通知”数据包中提供的 TCP 地址：端口，...
（这是我在我正在工作的应用程序中使用的方案在）
Some options are:
For your case (clients on a WiFi network), a UDP broadcast packet would suffice, it's multi-platform, and not too difficult to implement from the ground up.
Choosing this option, the two main algorithms are:
The server(s) send an "announce" broadcast packet, with clients listening to the broadcast address. Once clients receive the "announce" packet, they know about the server address. Now they can send UDP packets to the server (which will discover their addresses for sending a reply), or connect using TCP.
The client(s) send a "discover" broadcast packet, with the server(s) listening to the broadcast address. Once the server(s) receive the "discover" packet, it can reply directly to it with an "announce" UDP packet.
One or the other could be better for your application, it depends.
Please consider these arguments:
As a mix of the two options, a server could send a "gratuitous announce" broadcast packet once it comes up, and then it can listen for "discover" broadcast requests from clients, replying directly to one of them using a regular UDP packet.
From here, the client can proceed as needed: send direct requests with UDP to the server, connect to a TCP address:port provided in the "announce" packet, ...
(this is the scheme I used in an application I am working on)