couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Date Thu, 08 Nov 2012 18:52:23 GMT
On Thu, Nov 8, 2012 at 7:19 PM, Randall Leeds <> wrote:
> Benoit, could you explain a bit more what you mean by "the issue related to
> the coordinated node".
I was referrering to the scenario where a couchdb node acts as a
replication gateway only (where source and remotes are different nodes
than the one coordinating the replication).

> 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) <>wrote:
>>     [
>> 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:
>> >             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:

View raw message