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

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