[bittorrent] IO bound

Alan McGovern alan.mcgovern at gmail.com
Fri Apr 13 10:32:25 EDT 2007

Also, to do it the "smart" way with bitfield and have messages, you will
have to disconnect/reconnect peers in order to send a new BitField messages
when you change the pieces you're advertising. This can also lead to reduced
throughput, which i believe is one of the criticisms of the existing
superseeding method using bitfield/have messages.

On 4/13/07, Alan McGovern <alan.mcgovern at gmail.com> wrote:
> > 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:
> >
> >  http://bittorrent.org/fast_extensions.html#Suggest_Piece
> >   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 is
> > > the exact situation that the SuggestPiece message was designed to
> > combat!
> >
> > #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 like this:
> ------------
> 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
> suggestion.
> Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070413/7808076f/attachment.html 

More information about the BitTorrent mailing list