[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 gdt):

 I concur with the notion that the implementation should be "all the way"
 in either the unix style (which I would call client/server) or the p2p
 style.  (I am amused at being the canonical example of minimal.)

 This is also an argument for having v6 support working.  It's boggling
 that Twisted is so far (10+ years) behind the curve.

 On the notion of not arguing about better, two points:
  * we are talking about the protocol spec, not just the implementation
 behavior.  tahoe-lafs suffers from not having a clear separation between
 these.
  * obviously different people have different preferences and different
 situations, so (less obviously) both styles should be supported
  * given support for both styles, a good question is whether it  should be
 per-grid or per-system

 As I've been using tahoe-lafs with a private grid, each node (process) is
 a client or a server.  If the machine I want to use as a client happens to
 host a server node, then I run a client node (also).  With the current
 implementation, client nodes have the aliases file and thus must be per-
 user, and server nodes are about the grid.  (I am talking about the CLI,
 mounting, and WAPI, and reject the WUI as unsafe.)   And to make servers
 that have private addresses reachable and usable to all clients, I would
 have to configure NAT translation.  Given that, the client/server approach
 is sensible.

 People using the pubgrid may want maximal connectivity, but  if on a
 laptop/etc. they are going to find that servers come and go depending on
 whether their address is private or routable (and unfirewalled) at the
 moment.  (But this is not *currently* helpful as tahoe  does not work well
 with server churn (ticket:1209).)

 So, it could be that the introducer should have a "connect-to-clients"
 flag, and if set then 1) clients publish contact information and 2)
 servers try to connect to clients (and use connections in either
 direction).  I'd want this off, but it would be interesting to see what it
 should be on the pubgrid.  Perhaps the client should have a connect-to-
 clients config with yes/introducer/no, where "introducer" means to respect
 the config value from the introducer.  In a future with a distributed
 introducer function, this is just a piece of data that needs to be
 available from the function.  And it could be that the flag is passed in
 the setup of each connection, so reverse channels are not used to those
 who say connect-to-clients=off.

 It could also be that it's easier to make the flag be purely local,
 causing a client to publish contact information, causing a node that
 offers storage to connect to nodes that do not, trying to use the reverse
 channel, and allowing the reverse channel to be used.

 I think it's an important property that if on a node of mine I set
 connect-to-clients=off, then my client node will not publish anything (I
 realize the introducer still knows about it) and my server node won't try
 to make connections to clients.  (I do find repeated connection attempts
 to RFC1918 addresses annoying, and this helps but does not fix the issue.)

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