[bittorrent] Introductory/endgame algorithms

Andreas Aardal Hanssen bittorrent at andreas.hanssen.name
Mon Sep 26 09:42:58 EDT 2005

On Fri, 23 Sep 2005, Elliott Mitchell wrote:
>> It depends on how exactly you implement end-mode, but I'd think a good
>> starting point is if all chunks/pieces have already been requested.
>It was stated at one point that the overhead of end-game mode was 30%.
>This seemed high, but even without it being /that/ high I'm dubious of
>the usefulness.

I don't follow you at all here - the problem as I understand it is that
the last pieces you're downloading are likely to come from a very slow
link; not necessarily that the piece is uncommon.

>Of note, you cannot cancel a block once the other end has started sending
>it. If you're doing your queueing correctly, the other end will have a
>very short queue of pieces; ideally, zero. At this point cancels are
>useless, as they don't save bandwidth. What *does* make sense is to

Trying to tune the remote queue size to zero is silly. It's much better to
request as many blocks as you need to fill the pipeline, with some
reasonable upper limit. Then, cancels make a lot of sense. Of course you
can't cancel blocks in progress (that's pretty obvious), but if the host
is fast enough to send you all you request, then that host is likely to be
your #1 uploader, and so you won't be sending him cancels at all.

>download different blocks of a piece from different peers. The worst case
>then becomes you wait for one 32KB block from a particular peer, even a
>modem won't take long to send 32KB. The big issue is assigning blame if
>the piece hash turns out incorrect.

Indeed; that is the caveat of the endgame mode; if you get a single junk
block, it's hard to know who to blame.

>WTF are you doing with more than 100 peers? You've pushed the minimal
>BitTorrent protocol overhead above 5% of your entire bandwidth right
>there. The mainline peer counts are quite good for most circumstances.
>What clients should make easily changeable is the queue depth, *that*
>will help bandwidth far more often than more peers helps.

No, you misunderstand. Firstly, there's nothing wrong with keeping over
100 peers alive. Secondly, the point was that sending endgame requests to
them all will trash your bandwidth, and so I am interested in hearing how
other client authors have implemented their endgame algorithms.


Andreas Aardal Hanssen

More information about the BitTorrent mailing list