couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Peer Commit
Date Wed, 18 Feb 2009 23:40:57 GMT
On Wed, Feb 18, 2009 at 3:24 PM, Paul Davis <> wrote:
> On Wed, Feb 18, 2009 at 6:09 PM, Chris Anderson <> wrote:
>> I don't know the literature, but I have an idea for a shared
>> data-space across peer nodes (not in a cluster).
>> A replication helper, which tracks all known replicas, and their last
>> successfully replicated sequence num can provide to the user a list of
>> remote nodes that have knowledge of each update.
>> I think this works better with POST than GET replication... but by
>> logging GET replications we could have a rough idea as well.
>> If we track sequence id progress of all known replicas, we know with
>> what confidence local updates have been propagated to the network.
>> We can add secure messaging eventually, but for starters even a good
>> public data flow can get us a long way. The next step here is
>> peer-discovery.
>> It makes sense to me that distributed applications should expose their
>> replication state to the end user. Peer commit, or maybe eventual peer
>> commit, on an individual document update basis, does not make any
>> guarantees beyond the most basic, but still provides the ability to
>> publish content to a wide audience via a distributed network.
>> Example: When a user in a p2p mesh can see that N remote nodes are
>> keeping roughly up to date with her blog, it gives the proper
>> granularity of feedback. In the CouchDB Web, we don't count page hits,
>> we count replication streams.
>> I think it's the simplest metaphor, and avoids false abstractions like
>> bulk commits and order guarantees.
>> Chris
>> --
>> Chris Anderson
> Chris,
> Two questions.
> What happens when we move beyond a star topology into a true mesh. Ie,
> You've replicated Jan's blog, and I replicate from you?

I guess this provides only a minimum guarantee. Eg, a user knows that
nodes A, B, and C have the update. Node D could have the update
without the user knowing.

> Also, the number of replicas is essentially unbounded, assuming that
> we were even just keeping a list of (UUID, update_seq) tuples, we'll
> eventually have some headaches in terms of storage (depending on the
> answer to the first question). Though there may be other ways to track
> this information with bloom filters or some such.

I wonder if the current _local replication records could support this view?

Chris Anderson

View raw message