[bittorrent] Re: HAVE messages
David P. Mott
dpmott at sep.com
Mon Jun 20 12:54:34 EDT 2005
> Date: Mon, 20 Jun 2005 17:42:43 +0200
> From: Olaf van der Spek <olafvdspek at gmail.com>
> Subject: Re: HAVE messages (formerly "[bittorrent] Open letter to the BBC")
> On 6/20/05, David P. Mott <dpmott at sep.com> wrote:
>> Thoughts? Discussion?
> The traffic caused by HAVEs is probably lagely caused by headers and
> not by the HAVEs themselves. Therefore, you can already combine
> multiple HAVEs and send them at once.
Not according to the current spec. That was part of the original
MULTIHAVE extension proposal -- instead of specifying one piece index, you
could have multiple indices specified in the same message, and you'd do
that periodically instead of right away. And if that were to get bigger
than just sending the bitfield, then you'd do that instead.
> Also, how will your protocol implement rarest-first piece selection?
It would work the same, but the information that it would use would not be
up-to-the-minute current. That means that peers could drop from the swarm
(or, be added) and those events would not be immediately incorporated into
the rarest first (or whatever other) piece request algorithm.
Here's the thing: if I connect to 4 peers and they have what I need, then
I don't have to ask around anymore unless/until those four peers drop out.
Let's say that they each have exactly 0.25 of the torrent content which
doesn't overlap any of the other three, then I don't really care if
they're making progress. I only care about getting good download speeds.
With respect to download speeds, I may keep a peer list from the tracker
and optimistically connect to one of them at a time to see if they can
give me better download speeds. But, I wouldn't want to drop a connection
that would keep me from completing the torrent (i.e. don't drop peers that
have the only available piece).
I may also want to poll all of the peers that I can find in an agressive
fashion if I can't see an availability of > 1.0 for the torrent. But, if
I can see at least 1.0, I need not receive up-to-the-minute status from my
connected peers -- I already know where to find all of the pieces that I
I should also be able to gain some insight into the speed of each peer
from the tracker information (which, I agree, can be falsified). So I
could perhaps use that as a first guess as to which peers might give me
good download speeds. You can roughly measure how fast a peer is
downloading based on the current HAVE message implementation, but that
doesn't help you determine who will give YOU fast download speeds.
More information about the BitTorrent