relay server

[Brian Warner]

To enable endpoints that are both behind NAT boxes or firewalls to speak using Foolscap, it would be useful to provide support for an easy-to-use "relay server". We've kicked around a couple different approaches to this for ​Tahoe, and this one is currently our favorite.

The Foolscap negotiation protocol is specifically designed to provide for multiple Tubs listening on the same port. We build a Relay process to which the NAT-bound Tubs can attach, registering themselves with a (tubid, listener_rref) tuple. This listener_rref object has a single accept() method, which returns a handler_rref object. When B wants to connect to C, the FURL it uses will contain C's tubid but will have connection hints that point to the relay's listening socket. When B connects to the relay and says it wants to talk to tubidC, the relay (during the negotiation process) tells the listener_rref that it wants a new connection, gets the handler_rref, then switches into a simple proxy mode where it copies data from the B-side connection into remote_write() messages sent to the handler_rref. On C, the contents of these messages are written into a loopback TCP socket that mimics the data being exchanged between B and the relay. Responses generated by C get proxied backwards to the relay over the same connection.

This requires more code, but it's the "right way to do it" for relay. The intermediate relay doesn't get to see or corrupt the traffic that it is carrying, and the remote objects on B and C don't need to be aware that anything unusual is going on. C needs to register with the relay, and the FURL needs to be created with the right connection hints, but that can be done once at startup (instead of requiring that every single message be specially encrypted).

[Brian Warner]

this still feels like the best way to handle Foolscap traffic for NAT-bound hosts.