[bittorrent] Re: HAVE messages

Olaf van der Spek olafvdspek at gmail.com
Fri Jun 24 07:16:24 EDT 2005

On 6/24/05, Elliott Mitchell <ehem at m5p.com> wrote:
> > > those two numbers, we should expect to receive a wave of HAVE messages
> > > every 32 blocks we download. So with 32 peers each HAVE message will be
> >
> > Do you assume your peers download as fast as you?
> The calculations assumed so and this should reflect reality pretty well.
> If a peer has less bandwidth than you, you're likely to end up choking
> them; if the peer has more bandwidth than you, the peer is likely to end
> up choking you. So you do tend to get the effect of symetric bandwidth.

Only if the number of upload slots is equal.
If the bandwidth per slot is equal and the number of slots is larger,
than the total bandwidth will be larger and so will the HAVE

> > > I suspect weighting the random number generator may be a better approach
> > > than simply choosing those pieces first though. Notably at the start it
> > > is more notable that pieces all peers have are worthless (you won't be
> > > able to upload them), than that rare pieces are valuable.
> >
> > But not that valuable, as it's less likely you can complete them
> > before being choked.
> At the start pieces that are not common (say no more than 50% of peers
> have them) are *highly* valuable, as a peers may request those and
> unchoke in exchange; while common pieces are unlikely to be requested and
> so you'll remain choked. At the same time at the start rare piecs are
> dangerous as you could get choked partway through and not have any way to
> complete them. My main point is that the value of pieces isn't the simple
> "high value" versus "low value" that the rarest first model uses, there
> are many shades of grey there.

Very true, and I think the specs mention this too.

> > > At the same time I doubt 5 is sufficient in the general case. Figure DSL
> > > lines have around 50ms round-trip, and 2-10mbps (I've heard of 100mbps in
> > > some places). So 10-50KB in-flight, about 3 requests; perhaps the
> > > defaults aren't as bad as I thought, and 5 might work here. Local
> > > transfers, or very high bandwidth areas might do 5ms round-trip and
> > > 1000mbps though. In this case we see a need for 30 requests in-flight,
> > > and the defaults don't work.
> >
> > It's an issue when bandwidth * delay is high.
> Yes, which is more or less what that paragraph says. Bandwidth has been

The paragraph mentioned local transfers, but there the delay is tiny,
so I'd say it wouldn't apply to local transfers.

> increasing, *fast*. Latency hasn't been decreasing much. Hence queue
> depths need to be increasing.

More information about the BitTorrent mailing list