Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.198.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=h30KM6tJDstV1zB4ck7tUd52B/lHgtVgLtwaenlQX7doUFtnVuWqDsbQtQ7ncrC0PN
         dsH3R1SmV1Xq6kT1VtWnJLj8glGTIaHnzJRwiEUkdplAuzu5i0gv1Ys8vJ6Ar394xqUE
         0XWr0AQRscYHwJ8ZJer0Z8hhW/dRaJgJMmigs=
MIME-Version: 1.0
In-Reply-To: <84987d20902040618r59d5d497ifb5c66c1909034e6@mail.gmail.com>
References: <84987d20902040149v1f975975n3d62a6b62ca25441@mail.gmail.com>
	 <e2111bbb0902040559y7109a9b0w1957917f85f3ecc5@mail.gmail.com>
	 <84987d20902040618r59d5d497ifb5c66c1909034e6@mail.gmail.com>
Date: Wed, 4 Feb 2009 09:38:06 -0500
Message-ID: <e2111bbb0902040638q2e1090f6v2b277ddd5e47191b@mail.gmail.com>
Subject: Re: Questions about couchDB algorithms
From: Paul Davis <paul.joseph.davis@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Feb 4, 2009 at 9:18 AM, Alessio Pace <alessio.pace@gmail.com> wrote:
> Hi,
>
> On Wed, Feb 4, 2009 at 2:59 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>
>> On Wed, Feb 4, 2009 at 4:49 AM, Alessio Pace <alessio.pace@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I have just discovered couchDB and I'm very interested in knowing more
>> about
>> > the internal details of it, because apart from reading that is
>> multi-master
>> > and that the system is eventually consistent, I don't see much
>> informations
>> > about other various key design things (I apologize if I wasn't able to
>> find
>> > them), like:
>> >
>> > - update propagation through gossiping: based on any known algorithm?
>> >
>>
>> The current state of affairs in terms of keeping multiple nodes in
>> sync uses the baked in replication mechanism. At the moment it is up
>> to the user to ensure that nodes are kept in sync via these
>> facilities.
>
>
> Could you formulate a bit more about this?
>

Hmm. There doesn't appear to be much in the way of documentation on
replication beyond this:

http://wiki.apache.org/couchdb/Frequently_asked_questions#how_replication

Replication is basically a triggered async mechanism for ensuring that
all updates on node A are on node B (assuming replication from A -> B
obviously). It's incremental in operation, so repeatedly replicating
will only send new changes etc.

>
>> There is quite a bit of active development on this front
>> so it's best to stay tuned and see what comes out.
>>
>> > - group membership among the various site: how is it done, through
>> > gossiping? If so, based on any known algorithm?
>> >
>>
>> Not sure what you mean here.
>
>
> I mean: how does it deal with dynamic networks, where nodes join and leave,
> and you have to know onto which you can push/pull ? I am obviously talking
> about cases in which you can't list the a priori list of few cluster
> machines on text file and copy it on all the machines.
>

Replication is asynchronous and triggered. There's no constant
connections or anything of that nature. If you did pull replication
for everything then there'd be no issues other than on rejoining the
network a node may require a bit of time to catch up with the current
state of things.

>
>>
>>
>> > - are sites required to accept incoming connections (-> can I replicate
>> on
>> > nodes behind NAT?)
>> >
>>
>> Replication is both push and pull. So you just need to be able to have
>> your nodes behind NAT know when to trigger replication.
>
>
> You mean that if a public node generates an update, it can't be replicated
> to a natted target node unless it pulls the replication itself?
>

Either that or you'll need to setup port forwarding as in all things NAT.

>
> Thank you.
>
> Best regards,
> --
> Alessio Pace
>

HTH,
Paul Davis