[bittorrent] IO bound

Alan McGovern alan.mcgovern at gmail.com
Fri Apr 13 10:49:00 EDT 2007

Looks like we'll have to agree to disagree otherwise this could turn nasty

IO problems are exactly why the SuggestPiece message was introduced. Hence
why i'm advocating that you use a library that supports the FastExtensions
to "fix" the problem. I would hope that every library claiming full fast
peer support would only do so if it handled all messages in a "sane" manner.

All you need to rely on is that a client claiming to support the Fast
extensions doesn't completely ignore messages defined in the extension. That
shouldn't be an unreasonable expectation.


On 4/13/07, Adrian Ulrich <torrent at blinkenlights.ch> wrote:
> > Sorry, yes. I meant AllowedFast. And it does affect chunk selection ;)
> True, it does.
> Didn't think too much about it because in my client
> allowed-fast just creates an internal 'fake-bitfield' for this peer.
> The selection itself doesn't really change/know about this.
> > In other words, download the suggested piece unless you have a good
> reason
> > not to. Thats the way i've treated the message, and it makes the most
> sense
> > to me.
> ACK. But to me 'i do not care' is also a good reason ;-)
> So let's summarise:
> - Use fake-bitfields if you need to enforce selection
>    (Having IO-Problems would fit into this)
> - Use SuggestPiece if you trust your peers / do not
>    need to enforce piece selection.
> --
> RFC 1925:
>    (11) Every old idea will be proposed again with a different name and
>         a different presentation, regardless of whether it works.
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070413/07030707/attachment.html 

More information about the BitTorrent mailing list