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