11

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?

jscs
  • 63,694
  • 13
  • 151
  • 195
Lukas Leitinger
  • 631
  • 4
  • 15
  • The decentralisation will always be a problem and you cannot do much about that. I would just pick one of the devices in the network and it will from then on act as the server and all the other devices communicate with just that one device. That definitely makes it easier but I still wouldn't consider it easy. Could you maybe show us some relevant code or explain in more detail what you tried and what went wrong? – Xaver Kapeller Jul 29 '14 at 15:42
  • I considered a fluctuating server, but this also arises some problems. a) As it is a Wi-Fi network with smartphones, disconnects are going to happen frequently b) choosing a server and have all devices know which it is (or if there is already one) is really difficult. I'll edit the question with details. – Lukas Leitinger Jul 29 '14 at 15:52
  • I realise that, but you cannot deny that it is a lot easier than trying to have some transactional consistency in a decentralised network. If there is no one to decide the order and validity of each change than you are just going to run into insolvable problems. Just image there are two modifications at the same time on two different devices. Who decides if the modification is possible at all (imagine they are modifying the same thing). Who decides which one is before the other. If there is no central authority to make these decisions than you are going to have a lot of trouble. – Xaver Kapeller Jul 29 '14 at 15:56
  • I understand what you're saying, but in my data set is a list of items and each user can either have a vote on an item or not, so there is no direct conflict between the devices. – Lukas Leitinger Jul 29 '14 at 15:58
  • The most reliable way is for the devices to communicate with one dedicated device. If they modify something the server decides if it is possible and if yes the server syncs it to the other devices. If the server disappears another device is picked which from than on acts as the server. The tricky part here is of course picking the server and all that, but as long as you get that right I think you will find it a lot easier than the other option. – Xaver Kapeller Jul 29 '14 at 15:59
  • I don't know if it is applicable to your situation but you could just host a backend somewhere which takes the role of server. Of course you always need internet for that but then again what WIFI doesn't have an internet connection. Some simple GAE backend with GCM would be perfect. And you theoretically don't need for the devices to be in the same network anymore. – Xaver Kapeller Jul 29 '14 at 16:02
  • Are the items fixed or can they be added and removed? – Xaver Kapeller Jul 29 '14 at 16:03
  • I've thought of a backend like GAE, but obviously would much rather find a solution that stays in the Wi-Fi. Everybody can add items, the items get removed gradually – Lukas Leitinger Jul 29 '14 at 16:08
  • You are going to have to find a reliable way to sync those changes, but I suspect it's going to be difficult. Although there are some protocols for doing exactly that but I wouldn't describe implementing them as easy. A GAE backend might in the end be the simplest, quickest and best solution. Do you have experience with GAE? – Xaver Kapeller Jul 29 '14 at 16:12
  • What protocols do you have in mind? I don't have experience with GAE, but I know what approximately what it can do. – Lukas Leitinger Jul 29 '14 at 16:19
  • You can also use [**Parse**](https://parse.com/docs/android_guide#objects) or some similar library. I would give that a try. Parse can pretty much handle all the synching and saving in the cloud and you just have to worry about the business logic. – Xaver Kapeller Jul 29 '14 at 16:35
  • I will keep watching this question, so if you make some progress or have some problems feel free to update it, I will be notified of all changes! – Xaver Kapeller Jul 29 '14 at 17:00
  • Interesting problem... I would suggest using Gossip techniques for device discovery & information propagation and Merkle trees for merging of changes. Obviously, it raises a lot more questions. The first that comes to mind is how to handle clock skew (vector clocks, etc.). Of course, any cloud-based solution is much easier & faster to implement, but P2P one would be much more elegant (assuming you have unlimited time & resources for this task :) – Wildfire Jul 29 '14 at 20:57
  • I've been searching a lot for a framework to implement the Gossip/Discovery approach. Do you have a recommendation? P2P would be quite beneficial for the requirements :) – Lukas Leitinger Jul 30 '14 at 05:39
  • @LukasLeitinger Nope, I'm not aware of any frameworks suitable for mobiles. I'm familiar with Gossip implementation in Apache Cassandra, but it doesn't look like a perfect fit. – Wildfire Jul 30 '14 at 22:02
  • Just suggesting another way of doing thigs - almost all devices today are connected to internet. Insted of them discovering each other, you can send their GSM/GPS coordinates to central server via internet and pull\push data for the location you need. – Jehy Aug 01 '14 at 07:44
  • @Jehy I already discussed this with him, I suggested [**Parse**](https://parse.com/docs/android_guide#objects) as a simple solution. – Xaver Kapeller Aug 01 '14 at 11:55

3 Answers3

6

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 )

Survey / Vote Pattern

or a Coalition-of-Nodes role-symmetry in a "Bus Pattern" Bus / Routing 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.

sub-protocol

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

Community
  • 1
  • 1
user3666197
  • 1
  • 6
  • 50
  • 92
  • Thank you for your extensive answer, but I think the way to go is with AllJoyn. If I can get it to work, I'm sure it's much less reinventing the weel as writing my own protocol (from whatever layer on). – Lukas Leitinger Aug 08 '14 at 05:29
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" (e.g. on the same wifi). But this solution again includes having a central server and, even more, access to the internet.

boky
  • 815
  • 5
  • 10
  • I don't have too much data (text only), but the requests happen quite fast and every device can send more than 1req/s by itself. I'll still look into it. – Lukas Leitinger Aug 06 '14 at 09:16
1

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.

scottt
  • 8,301
  • 1
  • 31
  • 41