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.

Answer 1

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" (e.g. on the same wifi). But this solution again includes having a central server and, even more, access to the internet.

Answer 2

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.

Answer 3

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. )