Opened 10 years ago

Closed 7 years ago

#149 closed Enhancement (duplicate)

support new official fast peers extension

Reported by: ironica Owned by: tiennou
Priority: Normal Milestone: None Set
Component: libtransmission Version: 0.82
Severity: Normal Keywords:
Cc:

Description

  • Reserved Bit: The third least significant bit in the 7th reserved byte i.e. reserved[7] |= 0x04

These extensions serve multiple purposes. They allow a peer to more quickly bootstrap into a swarm by giving a peer a specific set of pieces which they will be allowed download regardless of choked status. They reduce message overhead by adding HaveAll and HaveNone messages and allow explicit rejection of piece requests whereas previously only implicit rejection was possible meaning that a peer might be left waiting for a piece that would never be delivered.

The specificication is documented at the BitTorrent? site here: http://www.bittorrent.org/fast_extensions.html

Attachments (8)

newfastpeers.2.diff (19.9 KB) - added by tiennou 9 years ago.
newfastpeers.diff (19.9 KB) - added by tiennou 9 years ago.
newfastpeers.3.diff (3.5 KB) - added by tiennou 9 years ago.
Fix the piece priority code
newfastpeers.4.diff (3.4 KB) - added by tiennou 9 years ago.
Last part of the patch
fastpeers-fix-r3513.diff (3.6 KB) - added by tiennou 9 years ago.
Fixed the #ifdef'ed code, also rename a function for consistency…
fastpeers-fix-r3579.diff (4.0 KB) - added by tiennou 9 years ago.
Supersedes the r3513 patch, fix for the BT_HAVE_ALL message reported by charles
fast-peers-final.diff (11.4 KB) - added by tiennou 9 years ago.
This patch makes fast extension a reality ;-). But we still don't send those SUGGEST messages out at people
fast-peers.diff (2.5 KB) - added by tiennou 8 years ago.
Patch throttlling fast set generation.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 10 years ago by ironica

it looks like the only open-source projects supporting this as of now are ktorrent and bitsharp.

comment:2 Changed 9 years ago by charles

  • Owner changed from somebody to charles
  • Status changed from new to assigned

we've got some baby steps for this in r3122 thanks to a patch submitted by tiennou.

comment:3 Changed 9 years ago by tiennou

  • Component changed from Transmission to libtransmission
  • Milestone changed from Sometime to 0.90
  • Owner changed from charles to tiennou
  • Status changed from assigned to new
  • Version changed from 0.6 to 0.82+

Here comes another (part of the) patch for Fast Peers... Now we actually DO something with these new messages ;-).

I'll make another patch to add superseeding (there are things related to superseeding in there that are currently unused).

(I changed the trac properties to find this ticket easily, sorry if this is a problem)

comment:4 Changed 9 years ago by tiennou

  • Status changed from new to assigned

Fixed some errors I made (freeing good requests is bad ;-)). Now I'm able to run this without asserting...

Changed 9 years ago by tiennou

Changed 9 years ago by tiennou

Changed 9 years ago by tiennou

Fix the piece priority code

Changed 9 years ago by tiennou

Last part of the patch

comment:5 Changed 9 years ago by charles

  • Milestone 0.90 deleted

status update: it's all committed, but still turned off. I'd like it to see some testing before 0.90 is released, and the nightly builds are currently broken, so there aren't many testers to be had. Removing from the 0.90 checklist for now.

comment:6 Changed 9 years ago by tiennou

Right now we don't follow closely the spec, as all requests are ditched when we choke a peer (The code that did that has been wrapped inside #if 0/#endif). We should check if the request is for a fast-allowed piece before ditching it from the request list. I'm not sure how to do this though, as this would impact non FPE peers... A nice 'extension' to this would be to fast-allow pieces even to peers that don't support FPE, but that's not expliciltly stated in the spec (and a non FPE-enabled peer would have no way to know which pieces are fast-allowed).

Changed 9 years ago by tiennou

Fixed the #ifdef'ed code, also rename a function for consistency...

Changed 9 years ago by tiennou

Supersedes the r3513 patch, fix for the BT_HAVE_ALL message reported by charles

Changed 9 years ago by tiennou

This patch makes fast extension a reality ;-). But we still don't send those SUGGEST messages out at people

comment:7 Changed 8 years ago by charles

  • Milestone set to Sometime

comment:8 Changed 8 years ago by dak180

This may be useful: Fast Extension

comment:9 Changed 8 years ago by charles

  • Resolution set to invalid
  • Status changed from assigned to closed

You know, absolutely zero people have requested this feature in the last eight months.

comment:10 Changed 8 years ago by jah

  • Resolution invalid deleted
  • Status changed from closed to reopened

Possibly because people will never use this feature directly, they don't even know it exists. However other clients like Mainline have implemented it, and it does seem to improve performance. What was wrong with the patches which were committed? If you need someone to test i'd be happy to do so...

comment:11 Changed 8 years ago by mezz

See TheSHAD0W's comment about Fast protocol extensions:

http://forums.degreez.net/viewtopic.php?p=28161

comment:12 Changed 8 years ago by charles

The patches that were submitted caused a huge speed hit while calculating which pieces were to be the "fast" ones. This was complained about extensively by users in the (early 1.0x?) releases.

comment:13 Changed 8 years ago by charles

  • Milestone changed from Sometime to None Set

comment:14 Changed 8 years ago by tiennou

Thanks to link to TheSHAD0W's comment above, here's a patch that will delay the fast set generation by a number of seconds after a peer connects. I also made it wait between each set exchange, because hammering others telling them "There's free stuff here" is a Bad Thing™ IMHO ;-).

TODO is coupling numbers of pieces to fast-allow with torrent piece size, as per TheSHAD0W comment.

Changed 8 years ago by tiennou

Patch throttlling fast set generation.

comment:15 Changed 8 years ago by charles

  • Version changed from 0.82+ to 0.82

comment:16 Changed 8 years ago by add

by end users who would like to contribute and start to use docs to learn cool stuff about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, duns china tour Apparel shoes bags Kitchen Food and Wine Furniture) Flowers and Gifts Wall Art Computer Components I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are *much* better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs

comment:17 Changed 7 years ago by charles

  • Resolution set to duplicate
  • Status changed from reopened to closed

This ticket has been superceded by #1549. Closing as a duplicate.

Note: See TracTickets for help on using tickets.