This issue is still unresolved, but my guess is that it's due to buggy firmware in the xDSL/cable modem or router. Reports on the mailing list seem to indicate that transfers complete without issue if the download rates are low. It seems that some people have come up with some very creative workarounds to deal with this, such as stopping the transfer if it gets too fast and restarting.

Limiting the download rate is much harder than limiting the upload rate, because one can only really control the rate at which packets leave the system. The rate at which they arrive is determined by the originating systems and any routers, gateways, or traffic shapers along the path. However, there are several ways that software can achieve the effect of limiting the download rate -- they amount to basically dropping some packets if they're coming in too fast, which will cause the TCP/IP stack of the sender to back off somewhat.

For those having these sorts of problems, here are the methods of which I'm aware to limit the download rate:

• For Windows, the Netlimiter program claims to be able to limit both the download and upload rate of individual programs or connections. The program is still in beta-testing, and it shows. My initial trial of it was not positive: it reported vastly wrong figures of its estimation of the BitTorrent program upload rate, its sockets wrapper broke Apache and rsync-over-ssh on my cygwin system, and its installer was ill- behaved. Finally, it is not free software, in both the "free speech" and "free beer" senses of the word. Not recommended at all.
• For Linux, *BSD, and Solaris, there is trickle, which is a userspace traffic shaper that uses the dynamic library preload facility. This has the advantages of requiring neither root privileges nor a recompiled kernel, and a simple command line e.g. trickle -u 20 -d 80 btdownloadgui.py --responsefile "%1".
• For Linux, you can try using the QoS features of the kernel to set an ingress filter. A recent mailing list post gives an example script that uses the tc (traffic control) command. Note that for this to work you will need root access and you may have to recompile the kernel (for netlink sockets and QoS.) See this page for information about configuring the kernel, this page about the ingress queueing discipline, and the Linux Advanced Routing & Traffic Control HOWTO as well as the Advanced Networking Overview for more information. The BSDs surely have traffic shaping as well, if anyone would like to contribute some links I will update this section.
• For Mac OS X (10.2.x only), Carrafix claims the capability to limit both upload and download rate for each port. Note that you must set a seperate cap for each port that BitTorrent uses in the Carrafix setup screen.
• Finally, another option is to limit the number of connections that BitTorrent makes. The number of connections does not directly correlate with download speed, however, since a client may be connected to a number of slow peers or just one or two very fast peers. The command line parameters that affect the download rate are: (see also the section How do I change the command line parameters in Windows? )
  
  

  --min_peers n

  determines the minimum number of peers that the BT client should be connected to before it will stop asking the tracker for more. The default is 20.

  --max_initiate n

  determines when the client should stop initiating new peer connections. The default is 40. Note: I believe, but am not positive, that this only affects outgoing, i.e. initiated connections. In other words the client will still continue to accept new connections past the number specified here, but will not initiate any further outbound connections.

  --request_backlog n

  determines the number of download requests to keep queued, defaults to 5. Setting this to a lower value should decrease the overall download efficiency and speed.

  So, you might try --min_peers 5 --max_initiate 10 --request_backlog 3 (for example) and see if it helps alleviate the sporadic disconnects or other related problems.

Note: Please let me know of any successes or failures at using these methods to cure the disconnect issue. I have no personal experience with the issue so I don't know what's worth trying.