Opened at 2010-08-15T05:03:15Z

Last modified at 2014-08-17T13:32:17Z

#1179 new enhancement

use μTP — at Initial Version

Reported by: zooko Owned by:
Priority: major Milestone: undecided
Component: code-network Version: 1.8β
Keywords: firewall availability Cc:
Launchpad Bug:

Description

μTP is a "low extra delay transport" designed and implemented by BitTorrent, Inc.. It might have some advantages over TCP for our purposes, such as allowing more interactive network usage (web page loads, ssh sessions) to proceed unhindered while Tahoe-LAFS is uploading or downloading files "in the background", navigating past NATs more easily (see related issues #169 (tcp hole-punching!), #49 (UPnP), and #50 (STUNT/ICE)), avoiding strange limitations on TCP connections (e.g. #605), or other benefits. It might also have drawbacks.

We would probably want to support both TCP-based and μTP-based transport for the forseeable future, choosing between them based on whether the peer supports μTP and whether the user wants this operation to be "foreground" (they are watching the movie as it downloads) or "background" (they are browsing the web while the movie downloads in the background).

See Brian Warner's and Greg Hazel's detailed discussion about what it would take to use μTP in Tahoe-LAFS in the mailing list messages below.

What's the next step on this? I'm not sure, but I think that the best strategy would be to concentrate on #510 (use plain HTTP for storage server protocol) and think about integrating μTP with that future HTTP-based Tahoe-LAFS protocol instead of with the current foolscap-based Tahoe-LAFS protocol.

Here are some tahoe-dev messages about it:

Here are some arguments about various aspects of μTP's design and implementation:

Change History (0)

Note: See TracTickets for help on using tickets.