[bittorrent] State of Super-seeding (bittorrent-list: tiennou7 at gmail.com exclusive)
tiennou7 at gmail.com
Sun Aug 12 10:56:18 EDT 2007
After some more tinkering, I'm still left with some question
regarding the specs, mainly with messages and the Fast Peers
What should I reply to a peer I have already sent a piece (and thus
I'm waiting for a HAVE message from elsewhere to seed again) ? The
spec says : "Until then, the client will not have access to any of
the other pieces of the seed, and therefore will not waste the seed's
bandwidth.", this looks to me like choking the peer, right ?
Another solution could be to REJECT (if peer support FPE), if choking
is an issue, but I really feel only choking will do to prevent the
peer from "[wasting] the seed's bandwidth"... So maybe making the
spec clearer ?
Combined with the FPE, I have the choice between sending a SUGGEST to
a FPE-enabled peer, or a plain HAVE. IIRC (I'm writing this offline,
so maybe I misread), the spec doesn't state clearly what a peer
should do after recieving a SUGGEST...
If I was sure sending a peer a SUGGEST would force it get the piece,
I'll be happy, but maybe I should just send a HAVE, from the reaction
On 8/9/07, Robb Topolski wrote :
> When Super-Seeding is active, Azureus starts in Super-Seeding mode,
> starting from piece 0 and delivering only pieces unique to the
> swarm. When Azureus reaches the final piece, or encounters another
> seeder, then it switches from Super-Seeding mode to Seeding mode.
> Azureus will not switch from downloading to Super-Seeding.
> uTorrent seems to stay in Super-Seeding mode (they call it Initial
> Seeding), delivering the rarest pieces. When set, it does not seem
> to ever drop out of that mode.
> Both methods, though very different, seem to deliver similar
> improved performance for the first seeder. I'll say more below.
> - Superseeding can be used at anytime, right ? The only thing is
> that I should be the only seed.
> John Hoffman suggests that it be used for low speed, low number of
> slots, first seeders only.
> My experience is that the speed and slots doesn't matter. The
> performance improvement scales across lower and higher speeds.
> uTorrent has taken this question even further, giving users the
> option to always Super-Seed. To me, users that choose to do that
> stretch the purpose somewhat (too much) further than intended,
> since it takes piece selection out of the hands of the peers and is
> unnecessary when holding no unique pieces. But the idea of "let the
> users decide" has not caused wide-spread abuse of the feature,
> IMHO, and may be a way for you to go.
> Good questions... I hope this helps.
Thanks for the tips. What I was planning to do is make the
superseeding kick in as soon as the conditions are met (I'm the only
seed, there's more than one peer in swarm), so that I can Superseed
on swarms that are already started. IIRC there was an issue with
Azureus not looking back after it had started super seeding (meaning
that if one of my superfeeded peers leave, it didn't sent again the
missing pieces)... My take is that the settings for Transmission
should be kept to a minimal, so I plan on not letting users fiddle
too much with Bittorrent's working (as opposed to uTorrent).
Side note : It seems the docs for the DHT spec have dissappeared from
bittorrent.org (though I managed to get them back from
web.archive.org). Strange thing is that the link fallback to the FPE
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent