Java：如何使多播IP InetAddress独占？
我试图使多播IP独占，即它可以被“锁定”，并且当它被“锁定”时，没有更多的MulticastSocket可以加入它。
是否可以？我该怎么做？下面是一些代码来解释我的情况：
String multicastIP = "224.0.0.1"; //multicast IP to "lock" later
InetAddress group = InetAddress.getByName(multicastIP); //create group
MulticastSocket multicastSocket = new MulticastSocket(8800); //Create a MulticastSocket using port 8800
multicastSocket.joinGroup(group); //join the group
//This is the part where I want to "lock" the group/IP
附加信息：
我正在开发一个网络游戏，其中单服务器到多个客户端的广播方案是通过此方法完成的。
曾经有一段时间，我们创建了两台服务器（碰巧具有相同的多播 IP），顺便说一句，客户端监听这两台服务器，从两台服务器接收消息。
我们想要发生的是让客户端只监听他们各自的服务器。
谢谢！ ：D
I'm trying to make a multicast IP exclusive, i.e. it can be "locked" and when it is "locked", no more MulticastSocket can join it.
Is it possible? How do I do it? Here's some code to explain my case:
String multicastIP = "224.0.0.1"; //multicast IP to "lock" later
InetAddress group = InetAddress.getByName(multicastIP); //create group
MulticastSocket multicastSocket = new MulticastSocket(8800); //Create a MulticastSocket using port 8800
multicastSocket.joinGroup(group); //join the group
//This is the part where I want to "lock" the group/IP
Additional information:
I'm developing a network game where the single server to multiple clients broadcasting scheme is done via this method.
There was a time we created two servers (that happen to have the same multicast IP) and incidentally, the clients listen to both servers, receiving messages from both servers.
What we want to happen is to make the clients listen only to their respective servers.
Thanks! :D
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
多播不会为你做这个。
您必须检查每个传入数据包 当您收到它时并将其与客户端发送的
（源地址，源端口）元组进行匹配。老实说，我认为使用多播对此没有太大优势。我见过的一种方法是使用多播进行服务发现，然后在发现“真正的”协议后使用单播。
编辑：对于 LAN 应用程序，多播可能是可以接受的。我只是会小心不要广播太多。 （多播本质上是对大多数交换机的广播；它们被 NIC 而不是网络过滤掉）也就是说，理想情况下确保服务器是发送多播流量的服务器，同时客户端单播更新到服务器。 （如果每个客户端多播所有其他客户端都可以看到的状态更新，那么拥有服务器的目的是什么？）
Multicast won't do this for you.
You will have to examine each incoming packet when you receive it and match it against the
(source address, source port)tuple the client is sending from.Honestly I don't think there is much advantage to using muticast for this. One approach I have seen is to use multicast for service discovery, and then use unicast for the "real" protocol once you have discovered it.
Edit: For a LAN application, multicast may be acceptable. I would just be careful not to broadcast too much. (multicasts are essentially broadcasts to most switches; they are filtered out by the NIC rather than the network) That is, ideally make sure the server is the one sending the multicast traffic while the clients unicast updates to the server. (if every client multicasts state updates that all other clients can see, what's the purpose of having the server?)