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

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 thoughts?

-dpmott




More information about the BitTorrent mailing list