[bittorrent] Queuing algorithm section
alan.mcgovern at gmail.com
Sun Aug 5 00:36:10 EDT 2007
I'm just going to give a heads up that i'm going to rewrite the 'Queuing
Algorithm' section on the bittorrent spec page. It's been under dispute long
enough that i'm going to resolve it.
The text will change to something along the lines of this:
1) A static queue is a bad idea.
a) Slow peers will have lots of unneccessary pending requests with a static
b) Fast peers won't have enough pending requests
2) Dynamic queue is a good idea:
a) The easiest way to do this is to give each peer a static queuedepth of at
least 2 blocks (2x16kB). For each 10kB/sec upload the peer has, add one
extra pending request. So, the pending requests can be calculated as: 2 +
(downloadSpeedInKilobytes / 10).
b) The pending requests should have an upper limit of 100. You shouldn't
have more than 100 pending requests off a single peer.
So, does anyone have any comments about that before i go ahead and make that
change. The 10kB/sec figure is one i chose from testing different values.
The choice of 10kB/sec means that for peers with large upload bandwidth,
you'll end up having a lot more data requested than they can supply in one
second. For example, with 500kB/sec available, there would be 832kB of data
requsted. For a peer with 2000kB/sec available, you'll have 3200kB of
pending requests. This should avoid most issues caused by a high latency
connection. Latencies of up to 1second can be handled with this algorithm (i
think, feel free to correct me ;) ).
Also, is it worth putting in a hard limit of 100? Should it be less? More?
Let me know your thoughts, unless someone can come up with a good reason as
to why this shouldn't be added, i'll change the text on
http://wiki.theory.org/BitTorrentSpecification on monday or tuesday.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent