implement relay: allow storage servers behind NAT #445

New Issue

warner · 2008-06-03T04:59:46Z

warner commented

2008-06-03 04:59:46 +00:00

Our roadmap.txt used to have "relay?" as Connection Management Step 5. This would allow storage servers to live behind NAT boxes.

Specifically, servers should be able to announce a FURL that goes through some willing relay server instead of pointing directly at the storage server. There are a couple of different Foolscap proposals to implement this (http://foolscap.lothar.com/trac/ticket/46).

Some more flexible store-and-forward routing scheme might also satisfy this goal.

Our roadmap.txt used to have "relay?" as Connection Management Step 5. This would allow storage servers to live behind NAT boxes. Specifically, servers should be able to announce a FURL that goes through some willing relay server instead of pointing directly at the storage server. There are a couple of different Foolscap proposals to implement this (<http://foolscap.lothar.com/trac/ticket/46>). Some more flexible store-and-forward routing scheme might also satisfy this goal.

warner added the

labels 2008-06-03 04:59:46 +00:00

warner added this to the undecided milestone 2008-06-03 04:59:46 +00:00

warner commented

2008-06-03 05:29:21 +00:00

See also #169, #49, and #50, about STUNT and hole-punching.

zooko commented

2009-09-19 22:12:29 +00:00

If you like this ticket you may also like #754 (merge manually specified tub location with autodetected tub location).

zooko commented

2009-12-13 04:03:31 +00:00

Hm, the Upload and Erasure-Coding Helper could address this problem, if you could run the Upload and Erasure-Coding Helper on a publicly reachable host where the behind-NAT storage servers could connect to it.

I think we should close this ticket as "wontfix". I'm not longer interested in Relay. Brian, what do you think?

Hm, the Upload and Erasure-Coding Helper could address this problem, if you could run the Upload and Erasure-Coding Helper on a publicly reachable host where the behind-NAT storage servers could connect to it. I think we should close this ticket as "wontfix". I'm not longer interested in Relay. Brian, what do you think?

warner was assigned by zooko

2009-12-13 04:03:51 +00:00

zooko commented

2009-12-13 04:04:07 +00:00

Or perhaps closed it as "fixed", treating the Upload Helper as the fix.

zooko commented

2009-12-19 14:05:44 +00:00

Oh wait I am still interested in this problem, because of this feature request: http://allmydata.org/pipermail/tahoe-dev/2009-December/003331.html . In that conversation Brian pointed out that upload-and-erasure-coding helper doesn't solve it because the current helper implements only immutable upload, and not immutable download, mutable upload, or mutable download.

Oh wait I *am* still interested in this problem, because of this feature request: <http://allmydata.org/pipermail/tahoe-dev/2009-December/003331.html> . In that conversation Brian pointed out that upload-and-erasure-coding helper doesn't solve it because the current helper implements only immutable upload, and not immutable download, mutable upload, or mutable download.

Sign in to join this conversation.