implement relay: allow storage servers behind NAT

[warner]

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]

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

[zooko]

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

[zooko]

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]

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

[zooko]

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.