Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.160.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2120324909.71110.1352156772346.JavaMail.jiratomcat@arcas>
References: 
 <1220942000.7101.1314138329138.JavaMail.tomcat@hel.zones.apache.org>
	<2120324909.71110.1352156772346.JavaMail.jiratomcat@arcas>
Date: Thu, 8 Nov 2012 10:19:30 -0800
Message-ID: 
 <CAAL6JQg2d7nL6d96qAPOG3ZfQQohe77uMio_SO07AYBp2ParWA@mail.gmail.com>
Subject: Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if
 local server has a dynamic port number
From: Randall Leeds <randall.leeds@gmail.com>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=f46d042ef55154d02804cdffe004

--f46d042ef55154d02804cdffe004
Content-Type: text/plain; charset=UTF-8

Benoit, could you explain a bit more what you mean by "the issue related to
the coordinated node".

I feel that TLS is the real security. I also favor using the _replicator
document ID as the checkpoint ID (it makes it impossible to have two
identical replications with different names, and I think this is good). I
would support the ability to specify the checkpoint ID, in any case, as I
believe Benoit is right that applications may want or needer finer control
over routing and checkpoints.


On Mon, Nov 5, 2012 at 3:06 PM, Benoit Chesneau (JIRA) <jira@apache.org>wrote:

>
>     [
> https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491019#comment-13491019]
>
> Benoit Chesneau commented on COUCHDB-1259:
> ------------------------------------------
>
> There is a potential security issue using a remote node id like in the
> second part of the patch. Local to local there is none.
>
>
> I am + 1 for fixing the issue related to the coodinated node.
>
> > Replication ID is not stable if local server has a dynamic port number
> > ----------------------------------------------------------------------
> >
> >                 Key: COUCHDB-1259
> >                 URL: https://issues.apache.org/jira/browse/COUCHDB-1259
> >             Project: CouchDB
> >          Issue Type: Bug
> >          Components: Replication
> >    Affects Versions: 1.1
> >            Reporter: Jens Alfke
> >            Assignee: Robert Newson
> >            Priority: Blocker
> >             Fix For: 1.3
> >
> >         Attachments: couchdb-1259.patch, couchdb-1259.patch
> >
> >
> > I noticed that when Couchbase Mobile running on iOS replicates to/from a
> remote server (on iriscouch in this case), the replication has to fetch the
> full _changes feed every time it starts. Filipe helped me track down the
> problem -- the replication ID is coming out different every time. The
> reason for this is that the local port number, which is one of the inputs
> to the hash that generates the replication ID, is randomly assigned by the
> OS. (I.e. it uses a port number of 0 when opening its listener socket.)
> This is because there could be multiple apps using Couchbase Mobile running
> on the same device and we can't have their ports colliding.
> > The underlying problem is that CouchDB is attempting to generate a
> unique ID for a particular pair of {source, destination} databases, but
> it's basing it on attributes that aren't fundamental to the database and
> can change, like the hostname or port number.
> > One solution, proposed by Filipe and me, is to assign each database (or
> each server?) a random UUID when it's created, and use that to generate
> replication IDs.
> > Another solution, proposed by Damien, is to have CouchDB let the client
> work out the replication ID on its own, and set it as a property in the
> replication document (or the JSON body of a _replicate request.) This is
> even more flexible and will handle tricky scenarios like full P2P
> replication where there may be no low-level way to uniquely identify the
> remote database being synced with.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>

--f46d042ef55154d02804cdffe004--