Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <AANLkTi=-+sfF=e+bn+qZNPuZn7SGQUQnqTZ3zDuuKTvP@mail.gmail.com>
References: <AANLkTi=-+sfF=e+bn+qZNPuZn7SGQUQnqTZ3zDuuKTvP@mail.gmail.com>
Date: Sun, 20 Feb 2011 04:58:25 -0800
Message-ID: <AANLkTikh1XoyHa0rvGJPvkLcowJ9JV7qG4UwJLhzf7pa@mail.gmail.com>
Subject: Re: Replication Behind Firewalls
From: Isaac Force <isaac@autognosis.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 17, 2011 at 5:33 PM, Ryan Ramage <ryan.ramage@gmail.com> wrote:
> In my application each user has a locally installed couch. I want them
> to be able to replicate with other machines they have (home, work,
> etc).
> Most people wont have public facing IP's or may be behind a firewall.
> I don't mind hosting a 'lookup service' but I want to be able to
> minimize the server traffic. I would prefer if the couch's could
> connect with each other direct.

If your users are technically savvy and willing to deal with port
forwarding, and the absence of replication when port forwarding isn't
an option is acceptable, a dynamic DNS provider would handle the case
where you want one public hostname for a client with an undefinable
public IP.

If the above conditions aren't true, I can't think of a reasonable way
to avoid requiring an intermediary of some sort. Inbound connections
can't be relied on with the prevalence of NAT and firewalls. If having
a public Couch for replication isn't an option, VPN with static IPs or
hostname registration with internal DNS would be the next easiest
solution. OpenVPN is relatively easy to set up and only uses an
outbound connection from the client side.

-Isaac