id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
46	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
[http://allmydata.org 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).
"	enhancement	new	major	undecided	introduction	0.2.4