[bittorrent] IO bound

Joris Guisson joris.guisson at gmail.com
Fri Apr 13 09:52:32 EDT 2007

What can I say, I'm a lazy bastard :-)

Truth is, I was gonna add this one day, but other things got in the way. And
then I forgot about it.

Either way, as long as the most popular clients (Azureus and utorrent) don't
support suggests, it is not much of an alternative for superseeding.


On 4/13/07, Alan McGovern <alan.mcgovern at gmail.com> wrote:
> KTorrent ignores suggest piece messages. I have not found much use for
> > them. Didn't feel like rewriting my chunk selection algorithm just so I can
> > take into account these suggestions.
> I would argue that you can't claim to support the fast extensions if you
> ignore completely certain portions of the extension ;) To claim support you
> should at least process any messages you receive, whatever about sending
> them out yourself. What if 1/2 the implementers of the fast extensions
> decided that they weren't going to support the FastPiece message because
> they didn't want to rewrite their chunk selection algorithm? That would mean
> that the faster bootstrapping into the swarm offered by this extension would
> be gone!
> While you may not have a use for SuggestPiece messages, other clients do.
> Super-seeding (initial seeding) can be handled *much* more cleaning with the
> introduction of the SuggestPiece message. You no longer have to resort to
> hacks like lieing about your bitfield and selective HaveMessage sending. Of
> course, if every client ignored SuggestPiece messages, any super-seeding
> logic based on SuggestPiece messages would fail miserably, despite it being
> better than the existing method.
> Sending fake bitfields is a messy solution. It was necessary *before* the
> SuggestPiece message was designed. In fact, i'd go as far to say as this is
> the exact situation that the SuggestPiece message was designed to combat!
> If every client obeyed the SuggestPiece message, you'd be *easily* able to
> control what pieces are being requested and saturate your bandwidth. You
> could load 10 pieces into memory, then send a SuggestPiece for each of those
> pieces to a different group of peers (possibly each group being 10 peers in
> size) meaning that each of your pieces would then be downloaded by 10 peers.
> Once thats done, you could load a different 10 pieces into memory and
> repeat. Thats roughly the kind of logic i'm planning on implementing, but
> that won't happen for a few weeks ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070413/20147d4c/attachment.html 

More information about the BitTorrent mailing list