[bittorrent] Introductory/endgame algorithms
sundell.software at gmail.com
Wed Sep 28 07:00:45 EDT 2005
On 9/27/05, Elliott Mitchell <ehem at m5p.com> wrote:
> You get major perform damage if you keep 100 peers alive. The number of
> HAVE messages is directly related to the number of peers. At 30 peers the
> HAVE messages account for 50% of the BitTorrent protocol overhead, or 1%
> of the payload size. At 100 peers, HAVE messages are accounting for 75%
> of the overhead, 3% of the size of the payload.
> Though 3% isn't a huge percentage, considering the size that payloads
> run, 3% is likely to be several megabytes. Do you see a reason that
> justifies an additional 2% overhead?
Some of us have bandwidth enough to actually need more than 100 peers,
having written clients that regularly upload to hundreds of peers at speeds
up to 50MB/s. I never manage to saturate my bandwidth, and if the torrent
has enough peers I try to upload to as many as possible to maximize my
Bandwidth is cheap, time isn't. A little overhead from HAVE messages and
keepalives doesn't hurt, especially when using epoll.
I'm limiting the number of peers that can download a single piece to 5 in
the endgame mode. With a 2 minute timeout this has shown itself to work well
in all cases I've encountered. Also the piece with fewest concurrent
downloads is delegated next. Peers with a transfer speed less than 4kb/s
only queue a single piece, while faster peers use a queue size of half what
they do in normal downloads.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent