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 alessio.pace@gmail.com
 designates 209.85.217.15 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;
        b=TadN5RBT/PbxrUaVzH/cxvuFlQGLYbYTD6Ygfj/f6evuXZPNHJok1o7/HXATex0uec
         Ac+MzqknLh28jrElZIYm3dNnKdFcrsXxbg5WbbwA5zyVc4xFU5Ixp1dgnNyzFWLcj0L6
         /V2gH/WSelkfDZiGUj9DypdU67+oEN90fPbgA=
MIME-Version: 1.0
In-Reply-To: <e2111bbb0902040638q2e1090f6v2b277ddd5e47191b@mail.gmail.com>
References: <84987d20902040149v1f975975n3d62a6b62ca25441@mail.gmail.com>
	 <e2111bbb0902040559y7109a9b0w1957917f85f3ecc5@mail.gmail.com>
	 <84987d20902040618r59d5d497ifb5c66c1909034e6@mail.gmail.com>
	 <e2111bbb0902040638q2e1090f6v2b277ddd5e47191b@mail.gmail.com>
Date: Wed, 4 Feb 2009 15:46:21 +0100
Message-ID: <84987d20902040646m4b8a26b6y112713762ac3b093@mail.gmail.com>
Subject: Re: Questions about couchDB algorithms
From: Alessio Pace <alessio.pace@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000e0cd2301ae4eb17046218d9a5

--000e0cd2301ae4eb17046218d9a5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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

--000e0cd2301ae4eb17046218d9a5--