If a downloader has a complete file, it uses its upload rate rather than its download rate to decide who to unchoke.įor optimistic unchoking, at any one time there is a single peer which is unchoked regardless of it's upload rate (if interested, it counts as one of the four allowed downloaders.) Which peer is optimistically unchoked rotates every 30 seconds. Peers which have a better upload rate but aren't interested get unchoked and if they become interested the worst uploader gets choked. It does reciprocation and number of uploads capping by unchoking the four peers which it has the best download rates from and are interested. The currently deployed choking algorithm avoids fibrillation by only changing who's choked once every ten seconds. Finally, it should try out unused connections once in a while to find out if they might be better than the currently used ones, known as optimistic unchoking. It should reciprocate to peers who let it download. It should avoid choking and unchoking quickly, known as 'fibrillation'. It should cap the number of simultaneous uploads for good TCP performance. There are several criteria a good choking algorithm should meet.
Also, choking lets each peer use a tit-for-tat-ish algorithm to ensure that they get a consistent download rate. TCP congestion control behaves very poorly when sending over many connections at once. That's built into the bittorrent protocol, and works through what is known as "choking."Ĭhoking is done for several reasons. The most important thing to remember is: The speed of your downloads is determined by the speed of your uploads. They are intended to give users more guidance than the settings recommended in the FAQ, but are by no means definitive.
See the peer_info structure in libtorrent for more detail.The settings below are suggestions. L – peer found via local service discovery (on local network).F – peer has participated in a piece that failed hash.P – uTP socket (flag not present in older versions of libtorrent).I – incoming connection (peer initiated connection to us).? – peer doesn’t want what we have but we’re not choking them.u – peer wants what we have and we are choked (peer wants us to upload but we won’t).U – peer wants what we have and we are not choked (usually uploading).K – peer doesn’t have what we want but isn’t choking us.d – peer has what we want but remote is choked (want to download but they won’t).D – peer has what we want and remote not choked (usually downloading).Next edit line 224 of the JavaScript file deluge-all.js to add the highlighted lines (but you may want to keep it all squashed up in one line in the file, it doesn’t matter):įunction ms(e) If not peer.flags & peer.local_connection: So here are instructions on what to modify in order to get more information about peers displayed.įirstly you may want to pin the deluge packages on your Linux/Ubuntu host to prevent them from being upgraded in the future (and wipe out your modifications): sudo apt-mark hold sudo apt-mark hold sudo apt-mark hold deluge-commonĮdit the file torrent.py so that it returns more fields in the AJAX response to the query from the browser for peer detail to modify the get_peers() function to add the following lines:Įlif not peer.flags & peer.remote_choked:
I want more information – especially the flags (as uTorrent displays, or as close to).
The “peers” tab for a given selected torrent in Deluge is rather scarce of information.