[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490609#comment-13490609
]
Robert Newson commented on COUCHDB-1259:
----------------------------------------
I'll summarize my reasons for not finding a technical justification in your
veto as follows: "We do not trust the host:port pair today, we will not trust
the uuid substitute with this patch, no security aspect has changed". Your
argument implies that seeing foo:5984 now, and seeing foo:5984 five minutes
from now means that you are talking to the same machine. This is obviously
false. if we are talking to https://foo:5984, and we trust the certificate now,
and five minutes from now, then we are sure we are talking to the same machine.
All this patch does is give a stable identifier to a couchdb server. To date,
we have assumed that full-qualified hostname and port number is a stable
identifier. It is, up to a point.
So, I would like comments on whether the patch does what it claims, and on the
separate point about clarifying the meaning of the patch by using UUID in place
of Host and Port in the replication_id calculations.
I will also note that, at your step 3, replication could not resume, since the
node could not be contacted on the old port. A new replication, with the new
port, would start up, and I see no reason why it should redo from start.
All this said, I think we need other voices on this ticket now.
> 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
