You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Ryan Ramage <ry...@gmail.com> on 2011/02/18 02:33:07 UTC
Replication Behind Firewalls
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.
I see some options:
1) host a couchdb for each user that acts as a sync server. Least
preferable because most hosting cost and bandwidth.
2) Act as a 'connection proxy' So if couch A wants to talk to couch B
they both connect to a central server which basically proxies the
between the two. Still not preferable because the traffic between
couchdbs would become a hosting cost.
3) Act as a lookup service. An user would subscribe and add couches to
a list. We would hold the IP addresses and try to have the client app
punch a hole in the firewall to perform a sync.
Does anyone have thoughts or ideas about the pros/cons of each
approach? Has anyone done something like Option 3?
Cheers
Ryan
Re: Replication Behind Firewalls
Posted by Isaac Force <is...@autognosis.org>.
On Thu, Feb 17, 2011 at 5:33 PM, Ryan Ramage <ry...@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