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

 Replying to [comment:12 davidsarah]:
 >
 > I also disagree that we should be changing the behaviour to one style
 now and then changing it to the opposite style later. It makes more sense
 to have a config switch (but I don't know where that switch should be).

 Hm, well if we're going to converge on the minimal-unix style, this is
 mostly just a matter of eliminating the use of certain foolscap features.
 It isn't obvious how to eliminate them -- foolscap doesn't provide a way
 to turn them off. I mean features like: all objects in one foolscap tub
 can access all objects in the other foolscap tub as long as there is
 currently a TCP connection open to them. One simple way to make it so that
 this feature no longer allows clients to use an unrouteable server as long
 as that server's tub happens to have opened a connection to that client
 would be to stop running both clients and servers in the same tub! That
 appeals to me. Then if you want to run both a gateway and a server you
 have to launch two separate processes in your operating system.

 Another feature which should probably be eliminated if we're going to the
 minimal unix style is the foolscap feature of listing multiple alternative
 IP addresses or hostnames, possibly including ones that are not routeable
 from the public Internet, and having a client attempt to connect to all of
 them in parallel and then use whichever connection succeeds. This feels
 like kind of a loss -- that feature is cool because it allows two nodes
 behind NAT to connect directly to one another over the LAN, for example.
 The minimal unix way to do that is that they cannot talk to each other
 until their human manually configures the NAT, in which case their packets
 get routed to the NAT box and then back to their LAN, or the human
 manually configures their IP address to be the LAN-scoped IP address, in
 which case they can connect to one another directly.

 David-Sarah: the reason to go the rest of the way to one style now and
 then switch to the opposite extreme style later is that we plan to switch
 from foolscap to HTTP. Foolscap provides a lot of very cool features in
 the p2p style, and in fact it is hard to use Foolscap *without* the p2p
 style. HTTP would be hard to use in the p2p style. I think we should work
 with the tools rather than against them here.

 Whatever we do, I hope we don't let this ticket just lie here because
 there are differing opinions about which direction to head. Heading in
 either direction would be an improvement, in my opinion, where the
 measurement of value I'm using is "How hard is it for users to understand
 and predict the behavior".

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