[tahoe-dev] Tahoe-lafs and nodes behind NAT (behind another NAT)

[Brian Warner]

Jody Harris wrote:
> 
> That may be a real stumbling block for my "big plans." I was hoping to
> use tahoe-lafs as a apotheca populi (storage for the people). If "the
> people" is defined as "average internet home user," then there is no
> way to achieve this unless the introducer can act as a "tunnel" for
> the whole grid/cloud.

We've talked about this off and on.. the core issue is making it
possible for NAT-bound home users to provide storage space, and that
requires some kind of data path from an arbitrary client (also
NAT-bound) to all the storage servers.

(incidentally, I don't think this sort of "tunnel" functionality should
be an Introducer responsibility.. I'd like to restrict the Introducer's
job to telling everybody about everybody else, and give some other
component the job of helping everybody actually exchange data with
everybody else).

This gets you into the realm of STUN and STUNT and various hole-punching
techniques (tickets #50 and #169). It's also in the UPnP space (ticket
#49). The P2P community has been working on it for years, with varying
results. Skype is great at this, but their techniques are proprietary
and secret. In general, if you have some sort of coordination node
(possibly centralized, possibly running on any "supernode" that appears
to have a public IP), you can coerce two NAT-bound hosts to establish a
direct TCP connection to each other, but it's a hassle. UDP is
marginally easier, but then you have to build a suitable protocol on top
of UDP, whereas TCP is just so darn convenient.

It's easier to build public-IP relay servers (ticket #445), but
relatively expensive to run them, since all the data has to go through
the relay. In that scenario, someone who wants to offer storage space
(but who does not have a public IP) must talk someone (who does) into
spending bandwidth on their behalf. Then they publish the relay's
connection information. In Tahoe+Foolscap terms, they'd publish a FURL
that has a connection hint which points at the relay, and maintain an
outbound connection to the relay, along which the data of inbound
connections could be forwarded. We've put more thought into this one
than into anything else, see also foolscap#46.

You could also imagine a sort of store-and-forward system, in which you
upload your shares to a publically-visible holding bin, and then later
the "real" (but NAT-bound) server connects to that bin and pulls down
the shares they're supposed to hold. When a client wants to download the
share, they ask the bin, which tells the server, which *uploads* the
share into the bin, then the client can download it from the bin. This
would be a lot like the #445 relay idea, but slightly more asynchronous
(the bin-to-server transfer could happen leisurely, when the bandwidth
was available).


I agree that this would be a great feature to have. We haven't built it
into Tahoe yet because it's kinda hard. Building a basic relay would be
a good first step that would provide significant functionality.. that's
where I'd start.

cheers,
 -Brian

ticket URLs:

 http://allmydata.org/trac/tahoe/ticket/49
 http://allmydata.org/trac/tahoe/ticket/50
 http://allmydata.org/trac/tahoe/ticket/169
 http://allmydata.org/trac/tahoe/ticket/445
 http://foolscap.lothar.com/trac/ticket/46