use μTP #1179

Open
opened 2010-08-15 05:03:15 +00:00 by zooko · 0 comments

μ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.

Here are some tahoe-dev messages about it:

  • [//pipermail/tahoe-dev/2010-May/004381.html]
  • [//pipermail/tahoe-dev/2010-May/004396.html]
  • [//pipermail/tahoe-dev/2010-May/004397.html]
  • [//pipermail/tahoe-dev/2010-May/004398.html]
  • [//pipermail/tahoe-dev/2010-May/004400.html]
  • [//pipermail/tahoe-dev/2010-June/004405.html]
  • [//pipermail/tahoe-dev/2010-June/004407.html]
  • [//pipermail/tahoe-dev/2010-July/004669.html]
  • [//pipermail/tahoe-dev/2010-August/004861.html]

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

μ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. Here are some tahoe-dev messages about it: * [//pipermail/tahoe-dev/2010-May/004381.html] * [//pipermail/tahoe-dev/2010-May/004396.html] * [//pipermail/tahoe-dev/2010-May/004397.html] * [//pipermail/tahoe-dev/2010-May/004398.html] * [//pipermail/tahoe-dev/2010-May/004400.html] * [//pipermail/tahoe-dev/2010-June/004405.html] * [//pipermail/tahoe-dev/2010-June/004407.html] * [//pipermail/tahoe-dev/2010-July/004669.html] * [//pipermail/tahoe-dev/2010-August/004861.html] Here are some arguments about various aspects of μTP's design and implementation: * <http://forum.bittorrent.org/viewtopic.php?id=119> * <http://forum.utorrent.com/viewtopic.php?id=69592> * <http://forum.utorrent.com/viewtopic.php?id=69416>
zooko added the
code-network
major
enhancement
1.8β
labels 2010-08-15 05:03:15 +00:00
zooko added this to the undecided milestone 2010-08-15 05:03:15 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#1179
No description provided.