Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.198.231 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=nGGhhDWHye6ZNTkR6QzwuGbolJ1veCOGxiQDVnRGv4iJpjLvbA9QDSyxMaNMwfQkIX
         2KCmmdPTtS+N6R5NMSVQ7xAT/hpqMUp/hUfks4n9oxbq4NvpaeFt1nVZlinWL7ijK3dc
         WAbUKRticx/4kwPyIbymXBX/REVEd94TURHc8=
MIME-Version: 1.0
In-Reply-To: <84987d20902040646m4b8a26b6y112713762ac3b093@mail.gmail.com>
References: <84987d20902040149v1f975975n3d62a6b62ca25441@mail.gmail.com>
	 <e2111bbb0902040559y7109a9b0w1957917f85f3ecc5@mail.gmail.com>
	 <84987d20902040618r59d5d497ifb5c66c1909034e6@mail.gmail.com>
	 <e2111bbb0902040638q2e1090f6v2b277ddd5e47191b@mail.gmail.com>
	 <84987d20902040646m4b8a26b6y112713762ac3b093@mail.gmail.com>
Date: Wed, 4 Feb 2009 10:02:43 -0500
Message-ID: <e2111bbb0902040702n209bad7egad7f82e17a2ea68f@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

Don't forget the link that Ulises posted:

http://horicky.blogspot.com/2008/10/couchdb-implementation.html

There's a nice description of Replication there too.

On Wed, Feb 4, 2009 at 9:46 AM, Alessio Pace <alessio.pace@gmail.com> wrote:
> Hi,
>
> On Wed, Feb 4, 2009 at 3:38 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>
>> 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
>
>
> Yes I saw that unfortunately there is not much, I would have liked some
> informations on how replication is done more in detail.
>
>
>>
>>
>> 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.
>
>
>
> Yes, unless other less straighforeward techniques are employed.
>
> Thanks.
> Regards,
> --
> Alessio Pace
>