我正在为 iOS 和 Android 开发一个应用程序。基本功能是在没有中央服务器的情况下在 Wi-Fi 网络中的所有设备之间保持一组特定的数据同步。每个设备都可以修改该组数据。
目前的做法是通过 Bonjour/Zeroconf 发现其他设备，然后通过 ZeroMQ 将“更改消息”发送到所有设备。
由于这两个框架在实现时会造成很多问题，我想问一下这是否是实现此目的的正确方法。
我已经使用 Bonjour 和发送到所有设备的 HTTP 请求实现了大部分逻辑。问题仅仅是网络请求，由于网络故障，即使尝试了三次也无法收到。我想对一般状态或更可靠的消息传递框架进行某种重构。
传播信息和发现所有设备的某种 Gossip 方法会更好吗？
最佳答案
简单的方案无法立即满足所有要求。
既不是成为按需服务器的临时角色不对称，也不是像“调查(每个人投票)”那样决定改变(图-s 由 nanomsg.org 提供 )
或“总线模式”中的节点联盟角色对称
本身满足所有要求。
持续发现“阶段”
是一项作为连续 self 识别操作的任务，以便向节点联盟提供相关信息集，在投票期间等待谁，不等待谁。反过来，当广播 <aListITEM> 变化并期望投票得到它的节点联盟“邻里”支持时是公平的。
Pieter Hintjens 的 400 多页书 The ZeroMQ Guide - for Python Developers, Chapter 8.3 将为您提供关于自主抢先和/或合作发现的一些初步见解以及前面章节中关于 WiFi 的一些评论.另请注意 >>> Limitations on WiFi SSID L3 ARP based discovery 中关于 ISO-OSI-L2/L3 不确定性的结束语。
<aListITEM> 的方法改变当前节点联盟的传播
只是在节点联盟内部实现的另一个子协议(protocol)(层)。
带有“调查”投票的总线或某种混合可扩展正式通信模式是否满足所有要求？
也许是，也许不是。
首先列出能够“针对”此类强制性功能集进行设计的所有要求。
其次，验证，该功能集对于每个节点都是合法且可行的，将动态成为/不再是节点联盟的成员。
第三，设计无阻塞、 self 恢复的社区——一个higher-order-FSA-of-FSAs——具有足够的握手、重新同步/看门狗/超时和传播 <aListITEM> 更新和投票机制，以便这些满足强制性设计功能集。
不要依赖现成的原语(以“弯曲”强制性设计功能集为代价以满足库中可用的原语，而是开发另一个，一种新的高阶正式通信模式信令，由库原语组装而成，因此它符合整个规范。)
关于java - 如何在 Wi-Fi 中的设备之间同步数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25019324/