[bittorrent] State of Super-seeding (bittorrent-list: tiennou7 at gmail.com exclusive)

tiennou 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  
Extension...

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  
is documented.

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

Etienne Samson


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070812/e44d35e6/attachment.html 


More information about the BitTorrent mailing list