implement relay: allow storage servers behind NAT #445

Open
opened 2008-06-03 04:59:46 +00:00 by warner · 5 comments
warner commented 2008-06-03 04:59:46 +00:00
Owner

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.
tahoe-lafs added the
code-network
major
enhancement
1.0.0
labels 2008-06-03 04:59:46 +00:00
tahoe-lafs added this to the undecided milestone 2008-06-03 04:59:46 +00:00
warner commented 2008-06-03 05:29:21 +00:00
Author
Owner

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

See also #169, #49, and #50, about STUNT and hole-punching.
zooko commented 2009-09-19 22:12:29 +00:00
Author
Owner

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

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
Author
Owner

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?
zooko commented 2009-12-13 04:04:07 +00:00
Author
Owner

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

Or perhaps closed it as "fixed", treating the Upload Helper as the fix.
zooko commented 2009-12-19 14:05:44 +00:00
Author
Owner

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.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#445
No description provided.