[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490448#comment-13490448
]
Jens Alfke commented on COUCHDB-1259:
-------------------------------------
It seems like overkill to get the IANA to assign a fixed port number to an app
that doesn't even listen on any external interfaces! The only use of that port
is (was) over the loopback interface to let the application communicate with
CouchDB.
Passing zero for the port in the config file didn't make the problem go away.
Apparently the replicator bases the ID on the actual random port number in use,
not on the fixed 0 from the config.
> What will prevents an hostile node to connect back to your node with the same
> id?
Hello, are you listening at all to what I'm writing? I've already said several
times that the app does not accept incoming connections at all. It only makes
outgoing connections to replicate.
And in general: obviously in any real P2P app there would be actual security
measures in place to authenticate connections, most likely by using both server
and client SSL certs and verifying their public keys. Once the connection is
made, _then_ database IDs can be used to restore the state of a replication.
> 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
