[tahoe-lafs-trac-stream] [tahoe-lafs] #1086: servers should attempt to open connections to clients

[tahoe-lafs]

#1086: servers should attempt to open connections to clients
------------------------------+------------------------
     Reporter:  zooko         |      Owner:
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  eventually
    Component:  code-network  |    Version:  1.7β
   Resolution:                |   Keywords:  introducer
Launchpad Bug:                |
------------------------------+------------------------

Comment (by zooko):

 tjgillies on IRC just had a confusing situation where he enabled storage
 service on a routeable node and this caused the gateway on that routeable
 node to start using a storage server on a behind-NAT node. This was
 understandably confusing to him.

 I think we should take one design strategy and "go all the way" with it,
 because either extreme is simpler for users to understand than what we
 currently have.

 "all the way" in the minimal unix style is that servers never attempt to
 open connections to clients, and if a node has both a server and a client
 in it then the client part of it will not re-use a connection which a
 different node earlier established to the server part of it. In other
 words, the only thing that ever works is if the server is routeable, and
 if you want to run a server behind a firewall or NAT then you have to
 learn how to configure that firewall or NAT in order to give your server a
 routeable IP address. It is important to understand that if we do it this
 way then **it is a bug** if connections sometimes magically work when your
 server doesn't have a routable IP address and you didn't explicitly
 configure your firewall/NAT to forward this port. It is a bug because it
 confuses users when things "sometimes" work and it irritates minimal-unix-
 style people like gdt when programs do clever non-standard things.

 "all the way" in the p2p style is that all nodes publish all of the "ways
 to contact me" that they can think of (including RFC1918 addresses and "my
 port number on localhost"), regardless of whether they are running a
 server or not, and all servers attempt to open connections to all clients
 and all clients attempt to open connections to all servers. This is non-
 standard and bothers expert sysadmins who want precise control over what
 TCP connection attempts are made, but it means that servers behind
 firewall/NAT can serve clients that are routeable without the server's
 operator having to learn how to configure their NAT. This can be
 understandable to users by explaining that the client and the server each
 try to connect to each other, and if it is possible for a TCP connection
 to be established in either of the two possible directions, then the
 client will be able to use the server. (Note that in addition to this
 approach supporting NATted-server + routeable client, it also supports
 client and server both on the same private network and neither one
 routeable from the public Internet.)

 Both approaches have their merits and drawbacks and let's not get
 distracted by arguing which is "better". Currently we have something that
 is ''almost'' like the p2p style, except that servers don't attempt to
 open connections to clients and clients don't necessarily publish their
 contact info (if they aren't offering a server).

 I think we should go ahead and make this style "complete" by the
 extensions I've requested in this ticket, which will I believe make it
 easier for users to understand and to use (even users who don't know how
 to configure their NAT device). I also think that in the future as we move
 to an HTTP-based transport instead of the current foolscap-based
 transport, we should probably switch to the extreme "minimal unix style".

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1086#comment:7>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage