[bittorrent] IO bound
alan.mcgovern at gmail.com
Fri Apr 13 10:29:23 EDT 2007
> > I would argue that you can't claim to support the fast extensions if you
> > ignore completely certain portions of the extension ;)
> Bitflu does also silently drop such messages. This still does conform
> to the fastpeers extension:
> Suggest Piece is an advisory message meaning "you might like to download
> this piece."
> There is no need for a peer to follow such a suggestion. So far i didn't
> even receive such
> a message in real-world.
Yes, it's an advisory. And yes, it does have real world uses. Such as in the
case where you have IO bound seeding. Whether you choose to drop it or use
it, there are cases where it will improve performance dramatically.
> 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?
> FastPiece == AllowedFast ?
> AllowedFast does not mess witch chunk selection.
Sorry, yes. I meant AllowedFast. And it does affect chunk selection ;) Peer
X sends me an "AllowedFast" message. That tells me i can download a
particular piece off them *without* being unchoked. Therefore my chunk
selection algoritm has to take into account the fact i can now download
*while being choked* and that i can only download pieces that a peer has
explicitly said they will offer my while i am choked.
Thats two major modifications right there ;) Implementing the selection of
AllowedFast pieces is harder than implementing SuggestPiece messages as it
requires you to know you can download a piece while choked.
> 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
> > the exact situation that the SuggestPiece message was designed to
> #1 Sending SuggestPiece means:
> -> Download piece X if you like to do...
> #2 Sending a fake bitfield is somewhat different:
> -> You can download piece x,y,z but nothing else from me
> This 2 solutions are not equal.
> #1 'suggests' something while #2 enforces something.
True. Personally, i'd say that the wording of the suggest piece message
could be improved. One interpretation is that it's merely an advisory as the
peer sending you that message has no knowledge of whether you've already
picked that piece off a different peer or not.
If i were to rewrite the text for the SuggestPiece message to mean something
If you receive a suggest piece message from Peer X for Piece Y, you SHOULD
request Piece Y from Peer X UNLESS you are already requesting Piece Y off a
different peer. If there are already pending requests on Peer X, you SHOULD
enqueue Piece Y so that as soon as the existing requests are fulfilled,
requests for Piece Y WILL be sent.
In the case where you receive multiple SuggestPiece messages for the same
piece, it is your discretion which peer you should request the piece off.
In the case where one peer sends multiple SuggestPiece messages, it can be
taken as a sign that each suggestion is equally valid.
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. If someone suggested you download a piece, they probably have a good
reason for suggesting, therefore unless it doesn't suit, obey that
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent