How to synchronize data amongst devices in Wi-Fi

Question

I am developing an app for iOS and Android. The basic functionality is to keep a certain set of data synchronized across all devices in a Wi-Fi network without a central server. Every device can modify that set of data.

The current approach is to discover the other devices via Bonjour/Zeroconf and then send the "change messages" to all devices via ZeroMQ.

As both Frameworks cause quite a lot of problems to implement I am asking if this is the correct way to accomplish this.

I had most of the logic implemented with Bonjour and HTTP-Requests sent to all devices. The problem was simply network requests which would not get received even after three tries because the network failed. I want to have some kind of reconstruction of a general state or a more reliable messaging framework.

Would some kind of Gossip approach to spread the information as well as discover all devices be better?

Answer 1

Simple schemes do not match all requirements right from the box.

Neither an ad-hoc role-asymmetry of becoming a Server-on-demand so as to decide upon a change as in "Survey (Everybody Votes)" ( Fig.-s courtesy nanomsg.org )

or a Coalition-of-Nodes role-symmetry in a "Bus Pattern" meets all the requirements per-se.

---

A Continuous Discovery "Phase"

is a task to be operated as a continuous self-identification, so as to yield the Coalition-of-Nodes the relevant set of information for whom to wait during the voting and for whom not. Reciprocally, when it is fair for the to broadcast < aListITEM > change and expect a voting to be supported by it´s Coalition-of-Nodes "neighbourhood".

Pieter Hintjens' 400+ pages book The ZeroMQ Guide - for Python Developers, Chapter 8.3 will give you some initial insights on autonomous preemptive and/or cooperative discovery plus some remarks on WiFi are in previous chapters. Also kindly note a closing remarks on ISO-OSI-L2/L3 uncertainties in >>> Limitations on WiFi SSID L3 ARP based discovery

---

Methods for < aListITEM > change propagation accross the current Coalition-of-Nodes

is just another sub-protocol ( layer ) to be implemented inside the Coalition-of-Nodes.

Does a Bus or some hybrid Scaleable Formal Communication Pattern with "Survey" Voting meet all requirements?

Maybe yes, maybe no.

First list all requirements to be able to Design "against" such a mandatory feature set.

Second, validate , that the feature set is legitimate and feasible for each and every Node, that will dynamically become / cease to be a member of the Coalition-of-Nodes.

Third, design the non-blocking, self-recovering community -- a higher-order-FSA-of-FSAs -- with adequate handshaking, re-synchronisation / watchdog / timeout(s) and propagation of < aListITEM > updates & voting mechanisms, so that these meet the mandatory design features set.

Do not rely on ready-made primitives ( at a cost of "bending" mandatory design feature set so as to meet the library-available primitive, but rather develop another , a new, higher-order Formal Communication Pattern Signalling , being assembled from library primitives, so that it meets the whole specification. )

Answer 2

I don't know about the specifics of your problem, but:

• if you don't have A LOT of data
• if your updates are not very frequent (> 1 req/s)

could a broadcast UDP message work?

If you query the network and get the broadcast address, that could be an easy way to distribute/query for information without needing to send it to each device individually. Of course, UDP is not reliable so you would need to implement some kind of "query" mechanism where the device would ask for updates once it (re)connects to a network.

Only other, more reliable, option that I could think of would be using platform's push notifications. In that case Apple/Google will make sure your messages get delivered, your only job is to keep a list of devices in "a group" (eg on the same wifi). But this solution again includes having a central server and, even more, access to the internet.

Answer 3

Getting client-server stuff working reliably can be quite challenging. especially cross-platform; there always seems to be one more edge-case that needs to be resolved. Rather than rebuilding the wheel, I recommend using an existing library where someone else has already worked out all the kinks. I haven't used it for anything beyond a prototype yet, but the AllJoyn open-source project looks very promising. Another option is the Google Nearby APIs , which at the moment are only for Android and iOS.