<div class="gmail_quote">On Thu, Dec 17, 2009 at 5:24 PM, Brian Warner <span dir="ltr"><<a href="mailto:warner@lothar.com">warner@lothar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Jody Harris wrote:<br>
<br>
> Well, I figured it out.<br>
><br>
> If you have a helper configured, you can "defeat" multiple layers (at<br>
> least two) of NAT addressing problems.<br>
<br>
</div>There are actually two potential things going on here.<br>
<br>
The first is that a helper acts as a sort of proxy. Suppose you have<br>
your CLIENT1 and there's a SERVER2 out there that you want to store<br>
shares on, but both machines are behind NAT boxes and can't accept<br>
inbound connections. If CLIENT1 is configured to use HELPER3, and<br>
HELPER3 is publically-visible, then the CLIENT1->HELPER3 connection<br>
works, and the SERVER2->HELPER3 connection works, and the helper will<br>
encode the client's shares and send them on to the server.<br>
<br>
Unfortunately the Helper is not complete: it only helps with immutable<br>
uploads. There's no fundamental reason why it couldn't be enhanced to<br>
help with the other three operations (immutable download, mutable<br>
upload, mutable download), but we didn't write the code to do that,<br>
because the main purpose of the Helper is to improve upload speed by<br>
moving the post-encoding expanded bandwidth requirement off of the<br>
(slow) consumer ADSL line over to the (fast) intra-colo LAN connection.<br>
The other three operations don't benefit very much from this (we assume<br>
that mutable files are usually small), so we didn't bother.<br>
<br>
That means that, while the uploads might work, the downloads might not,<br>
and directory operations (which use mutable files) might not. Those<br>
operations may use a smaller set of servers than you'd expect.<br>
<br>
The second thing going on is that Tahoe's connection layer makes<br>
bidirectional connections between everything, and a successful A->B<br>
connection can then be used for messages from B to A. In the normal<br>
case, when all nodes are publically visible, this results in<br>
redundant+discarded connections (if the A->B connection is established<br>
first, the subsequent B->A connection is rejected).<br>
<br>
Basically, every node that might possibly want to be a client (which is<br>
all of them, until we change the code to create "server-only nodes")<br>
will try to establish connections to every server they hear about. And<br>
every node that runs a storage server (controlled by the tahoe.cfg<br>
[storage]enabled flag) will announce themselves to every client. So if<br>
SERVER2 is behind a NAT box, but CLIENT1 is publically-visible, and<br>
CLIENT1 is also running a storage server (so it's really<br>
CLIENT1+SERVER1), then SERVER2's never-turned-off client code will<br>
establish a connection to SERVER1, which is then available for when<br>
CLIENT1 wants to talk to SERVER2.<br>
<br>
So the aggressive bidirectional connection establishment code can save<br>
connectivity when a few "server" nodes are actually behind NAT boxes. I<br>
think the result is that a grid can tolerate a single NATted node<br>
without loss of functionality. Two NATted nodes won't be visible to each<br>
other, but will be visible to everyone else, etc.<br>
<br>
This also means that if you have a client with a public IP address, you<br>
might want to leave the storage server enabled (but perhaps mark it<br>
readonly, or set the reserved_space really high, to avoid getting any<br>
shares), since that will cause other nodes to connect to you, which<br>
might get you access to NATted servers that would otherwise be<br>
unreachable.<br>
<br>
Of course, if you're running a server, you should really make sure it's<br>
reachable by all of your clients, otherwise it's not providing much<br>
utility to them, and relying upon this trick isn't a big improvement. If<br>
the server is behind a NAT box but it is possible to set up a port<br>
forwarding from a static IP address, then the tub.location configuration<br>
setting can help teach the rest of the grid where to find it.<br>
<br>
cheers,<br>
-Brian<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>jody</div></div>