我们应该使用什么广播/多播方法？
我们正在创建一个移动应用程序，该应用程序将受益于了解同一网络上另一个实体的 ID（假设两部手机位于同一 WiFi 网络上）。
我们希望“主”应用程序发送一个 ID，“从”应用程序可以拾取并存储该 ID。无论“从设备”何时登录到网络，它都应该识别主设备（获取主设备的 ID）并使用它，直到它获得新的主设备（来自另一个网络和新的主设备）。
我们要求该实现在 iOS 和 Android 下可行（最好也在 J2ME 下），并且该方法最有可能在正常网络配置中可用（包括公共 WiFi 设置，只要客户端都具有适当的网络访问权限）。
我们应该使用什么广播/多播方法？
We are creating a mobile App that will benefit from knowing the ID of another entity on the same network (presuming the two mobile phones are on the same WiFi network).
We would like the “master” App to send out an ID that the “slave” App’s can pick up and store. Regardless of when the “slave” logs on to the network it should identify the Master (get the ID of the Master) and use it until it gets a new one (from another network and a new master).
We require that the implementation is feasible under iOS and Android (preferably also under J2ME) and that the method most likely is available in normal network configurations (including public WiFi set-ups as long as the clients both have proper network access).
What broadcast / multicast method should we use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
公共 WiFi 连接的可用性几乎排除了 IP 层多播。
如果您只对同一子网内的应用程序感兴趣，则可以进行广播。我认为基站倾向于将所有连接的机器放在同一个子网上，而 3G 网络倾向于阻止加密狗之间的所有广播。
如果这失败了，那么另一种方法是建立一个大师层次结构，就像 MSN 一样。基本思想是更高级别的大师充当本地大师的目录。当然，您必须考虑到 IP 地址更改等情况，但作为一般规则，应用程序运行时间越长，它就越有可能建立附近其他人的列表。主站还可能注意到它的一些从站具有相似的 IP 地址（危险：NAT），并让它们进行推测性联系。
所有这些都需要相当通用的 TCP/UDP 功能，即使是 J2SE 也应该具备。
Usability on public WiFi connections pretty much precludes IP-layer multicast.
If you are only interested in Apps within the same subnet, you might be able to do a broadcast. I think base-stations tend to have all connected machines on the same sub-net, whereas 3G networks tend to block all broadcasts between dongles.
If that fails, then an alternative approach is to have a hierarchy of masters, much like MSN. Basic idea is that a higher-level masters act as directories for local masters. Of course you have to make allowances for things like IP addresses changing, but as a general rule the longer-running an App, the more likely it will have built up a list of who else is nearby. Masters could also notice that some of its slaves have similar IP addresses (hazard: NAT), and get them to make speculative contact..
All this requires fairly generic TCP/UDP functionality, which even J2SE should have.