[bittorrent] IO bound

Adrian Ulrich torrent at blinkenlights.ch
Fri Apr 13 10:08:55 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:

 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.


> 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.



> 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.


IMO the protocol itself should keept simple (SuggestPiece is just bloat).
A smart client can do this kind of stuff with bitfield/have messages without
breaking/excluding existing implementations!



Regards,
 Adrian


-- 
 RFC 1925:
   (11) Every old idea will be proposed again with a different name and
        a different presentation, regardless of whether it works.




More information about the BitTorrent mailing list