[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2865: optionally re-enable start topology

Tahoe-LAFS trac at tahoe-lafs.org
Wed Feb 15 14:00:03 UTC 2017


#2865: optionally re-enable start topology
-------------------------+---------------------------
 Reporter:  lpirl        |          Owner:
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:  undecided
Component:  unknown      |        Version:  1.12.1
 Keywords:               |  Launchpad Bug:
-------------------------+---------------------------
 Sorry for annoying you folks with my use case again:

 As a consequence of fixing #2759 (with [https://github.com/tahoe-lafs
 /tahoe-lafs/commit/6061b6fc3cdeba5feeda8d3be6283e42e40401c7 this commit]),
 Tahoe cannot be operated in a star topology anymore (as also stated in
 [https://github.com/tahoe-lafs/tahoe-
 lafs/blob/0cea91d73706e20dddad13233123375ceeaa7f0a/NEWS.rst the change
 log]).

 IMHO, this is a very valid use case, since NAT is still reality and we do
 not have any hole-punching etc. yet. Using an overlay network is not
 always an option (resource constraints, constraints regarding the
 administrative rights, etc.).

 Looking at the diff of the commit linked above, I am not enough into the
 code to see if/how we could easily implement a switch for either using a
 separate Tub per connection or not.

 Could a switch to re-enable reverse connections to storage servers be
 implemented "easily" (undoing the privacy improvement for the sake of a
 working deployment)?

 For the environment that I have, I cannot use Tahoe>=1.12.0 at all (well,
 #2759 is still a privacy improvement but the consequences feel a bit too
 drastic :)).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2865>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list