P2Pish and presence information - best approach?

[Mark]

Jen’s session at Couch Connect and subsequent p2p mesh replication app brought forward some background ideas for a project. For this project one of the things I’ve been stuck on is the idea of presence information. Let’s assume for the moment:

1. We’re making some sort of ‘chat’ app - could be people or systems, just something that needs to pass information around.

2. We’re using some sort of soft mesh - maybe a spanning tree or similar but designed to deal with and without WAN connectivity to a central coordinating server.

3. We’ve solved the authentication/verification of content through public/private keys or flying unicorn protocols, or maybe that’s not needed because it’s going to be anonymous and there are no spammers/trolls using our app. Yes, I realize this is a hard problem and I’m hand waving.

4. There is a desire to know who/what are currently involved in the ‘chat’ within some sort of time window (x seconds).

5. We’re using CBL on the ‘devices’.

Let’s be open to other protocols but for this thought experiment I was trying to do everything in couchsync protocols.


Options as I see them:

1. Send a new heartbeat document at the end of time window with id of device/person. Pro: easy Con: lot’s of documents that would be difficult/slow to clean up.

2. Create a single heartbeat doc per device/person and continue updating it when online. Pro: less documents Cons: Lot’s of revisions; possible but unlikely revision collisions.


I lean toward #2 with the a follow on idea to keep the ‘presence’ information in a separate database from the ‘main’ database. Then, on Y number of database changes, do a quick compression to remove the revisions. If there is a revision conflict, deal with it somehow.

I’d love anyone’s thoughts on this approach so I can put this particular thought process to bed for a while.

Thanks!

[Jens Alfke]

On Jun 20, 2015, at 1:01 PM, Mark <mark...@gmail.com> wrote:

Jen’s session at Couch Connect and subsequent p2p mesh replication app brought forward some background ideas for a project.  For this project one of the things I’ve been stuck on is the idea of presence information.

Glad you liked the presentation. One of the things I worked on in the past was iChat, including the Bonjour IM system, so I’m definitely interested in presence.

2. Create a single heartbeat doc per device/person and continue updating it when online. Pro: less documents Cons: Lot’s of revisions; possible but unlikely revision collisions.

I think this is the better of the two approaches, but it’s still not ideal.

Problem 1: Lots of revisions, as you point out. The ForestDB storage in 1.1 handles this a lot better than the SQLite-based one does, because it proactively prunes old revisions when new ones are added. The default maxRevTreeDepth is 20, so at most 20 revisions of a doc will be kept around. But regardless of storage, the more frequently state is updated, the more replication traffic there will be.

Problem 2: When a device goes offline (app is backgrounded) it has to update its presence document, and then replicate it to other peers. But there are cases where that isn’t possible, like if the app moves out of range of the LAN or otherwise loses connectivity, or if the app crashes. The typical way around this is to put a timestamp on the presence document and give it a fairly short time-to-live, so that if the peer keeps updating it, they’re assumed to have gone offline. But now you have a conflict between timely notifications of offline state, vs. the number of updates. (If you have 20 peers each updating their state every minute, that’s an update every 3 seconds.)

If everyone’s on the same LAN, it works better to use Bonjour alone. That’s what iChat does. Your app’s published replication service is its presence. Bonjour is pretty good at keeping its state of the world up to date (well, in Yosemite it wasn’t, but apparently 10.10.4 fixed the regressions.)

—Jens

[Mark]

Ok, thanks for taking the time to respond to my thoughts. That’s pretty much what I assumed but I hadn’t considered Bonjour. Your point about updates every 3 seconds is interesting - doesn’t scale well for many peers or need for “real-time.”

I’ll just shove this back into my head and get back to work on current projects.

Have a great weekend.

> --
> You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/19F8D395-BECE-4D01-8C5C-DB43AF812D9F%40couchbase.com.
> For more options, visit https://groups.google.com/d/optout.