[tahoe-dev] uTP (low extra delay transport)

[Brian Warner]

On 5/27/10 5:39 PM, ghazel at gmail.com wrote:
> 
> It's a byte-pipe, just like TCP. uTP is very much like TCP with the
> LEDBAT congestion controller instead.

Ah, that does make life easier. I imagine the easiest approach would be
to create the Foolscap+SSL+TCP connection to ourselves, then relay the
SSL bytes back out the uTP connection, and vice versa. This "two socket"
approach is my current favorite for handling relays (my Foolscap
listener is behind NAT, but it's arranged for a public-visible node to
relay traffic for it.. in this case, the second socket would also be
Foolscap, but to the relay host).

In that case, we could run our future HTTP-based protocol over uTP as
well. And switching between "foreground" and "background" traffic would
be easy (although we'd need to manage two simultaneous connections to
the same server, which would take some internal changes).

> uTP can be plugged in to any transport which supports
> something that looks like recvfrom and sendto.

How does the uTP event loop work? Have you tried or been able to make it
work as a twisted ITransport?

Hm, now, how to actually take advantage of this..

* Foolscap needs to learn about uTP, probably via a new kind of
connection hint (uTP:HOST:PORT). The Connection side must know how to
perform the reactor.connectTCP equivalent, and the Listener must know
how to perform the reactor.listenTCP equivalent. Both need to be able to
create the loopback socket and then speak SSL over the second socket.
* servers (once we implement #466) can announce a uTP-based FURL in
addition to their TCP-based ones
* clients can establish two connections (using three sockets).
* NativeStorageClient will hold two RemoteReferences (uTP and TCP)
* the Uploader will get a background= flag, which tells it whether to
use the uTP rref or the TCP rref. Same for the Downloader.
* Repairer will set background=True, normal "foreground" operations will
set it to False


fun fun fun,
 -Brian