[bittorrent] IO bound

Alan McGovern alan.mcgovern at gmail.com
Fri Apr 13 09:45:34 EDT 2007

I just reread the spec, here's an excerpt from the SuggestPiece section:

The intended usage is for 'super-seeding' without throughput reduction, to
> avoid redundant downloads, and so that a seed which is disk I/O bound can
> upload continguous or identical pieces to avoid excessive disk seeks.

Case 1 is what i already mentioned. SuggestPiece's make SuperSeeding faster
and better.

Case 2 is exactly the problem that the OP has. Therefore if he sent
SuggestPiece messages and other clients took that suggestion, he'd be able
to avoid the excessive disk seeks which are causing him problems.


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/c70a289d/attachment.html 

More information about the BitTorrent mailing list