couchbaselite - iOS- peer to peer - Are there any restrictions/limitations?

37 views
Skip to first unread message

Sandra

unread,
Mar 6, 2015, 1:47:39 PM3/6/15
to mobile-c...@googlegroups.com
Hello,
    I'd like to know if there's any restriction in the P2P architecture, or any limitation on the number of devices that can "talk" to each other.

   In case my app doesn't have connection to sync gateway, it connects peer to peer to the devices found in an array which correspond to all the devices in the same local network. That means that they will all try to connect to the first device in the list, in case it is unavailable for some reason, they will try to connect to the next in the list and so on.
   What I want to ensure is that all devices have the same information, and when the internet connection is re-established, e.g the sync_gateway is available again, all the changes are stored in the server which is in the cloud.
  1.    Is this architecture ok for this scenario or shall we find a way to have only one mobile device acting as a server so that all communicate only to this one?
  2.     In case the above approach is acceptable, is there any limit on the amount of devices that can interact p2p?
  3.     When the sync_gateway is reachable again, is there anything we must take into consideration to avoid conflicts or data inconsistency?
  4. How does couch base lite detect that it no longer has connection to sync_gateway? is it only when we try to write in the database or also when reading? or is there any heart beat?

   I appreciate your clarifications,
   BR,
   Sandra

Jens Alfke

unread,
Mar 6, 2015, 2:04:59 PM3/6/15
to mobile-c...@googlegroups.com
On Mar 6, 2015, at 10:47 AM, Sandra <txm...@gmail.com> wrote:
  1.    Is this architecture ok for this scenario or shall we find a way to have only one mobile device acting as a server so that all communicate only to this one?
Yes, that’s ok. The replication protocol/algorithm was explicitly designed to support multi-master scenarios with arbitrary topologies between peers.

In a P2P system you do need to be careful about authentication, though. You can’t just trust any peer that you discover by Bonjour, or you could end up both exposing private data and allowing fake data into the database.

  1.     In case the above approach is acceptable, is there any limit on the amount of devices that can interact p2p?
There’s not a fixed limit, but the overhead will go up as the number of peers increases. The replicator won’t send revision bodies or attachments redundantly, but it does pre-flighting to check whether the peer already has a revision, and in a dense mesh network there can be a lot of that. We haven’t tested a scenario like that, but my hunch is that it would take dozens of peers before it became a problem. (The solution to it would be to use mesh-networking techniques like spanning trees to lower the number of redundant connections.)

  1.     When the sync_gateway is reachable again, is there anything we must take into consideration to avoid conflicts or data inconsistency?
Don’t try to push documents that aren’t yours to the gateway :) Or at least, not documents you don’t have permission to update. Otherwise the gateway will reject them. (Which shouldn’t cause serious problems, it’s just a waste of bandwidth.)

  1. How does couch base lite detect that it no longer has connection to sync_gateway? is it only when we try to write in the database or also when reading? or is there any heart beat?
That’s the replicator’s job. If you have a continuous replication running, it will be watching the network status and trying to keep a connection open. You can observe the CBLReplication to check when it goes offline/online.

—Jens

Sandra

unread,
Mar 11, 2015, 7:25:21 PM3/11/15
to mobile-c...@googlegroups.com
thanks a lot Jens  :)
Reply all
Reply to author
Forward
0 new messages