[bittorrent] Re: HAVE messages

Olaf van der Spek olafvdspek at gmail.com
Mon Jun 20 14:07:53 EDT 2005


On 6/20/05, David P. Mott <dpmott at sep.com> wrote:
> 
> > 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

Why not?
You can put multiple HAVEs in a singel TCP packet.

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

If you don't update your view of the world you won't be able to
execute rarest first properly.

> I should also be able to gain some insight into the speed of each peer

You should? How?



More information about the BitTorrent mailing list