Version: SVN (using KDE KDE 3.4.2) Installed from: Compiled From Sources Compiler: gcc 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1) OS: Linux Torrents with huge amounts of seeds generally download extremely fast with most torrent clients, but not with Ktorrent, often instead stalling out or staying at some extremely low speeds. Ports are all properly forwarded and specified in the configuration. This happens no matter how many connections I allow Ktorrent to use without a speed limit being set on uploads or downloads. An example can be found at http://torrentspy.com/directory.asp?mode=torrentdetails&id=343341 which is a ~113MB torrent with at the moment, around 250 seeds and only 10 leechers. With Azureus and several other torrent clients, I quickly get over 500k/sec, maxing out my connection. At the moment, with the current svn code compiled only a few minutes ago, I'm getting peaks of 25k/sec with an average of about 5k/sec with long times where the torrent seems to be completely stalled.
Post some more torrents, my initial tests show that KTorrent and Azureus get around the same speeds (between 20 and 40 KB/sec). No peeks to 500 KB/sec, but such a peek might have relied on a single really fast seeder that maybe isn't online this early in the morning. You didn't test both clients at the same time did you ? If KTorrent can't bind to the port you choose it will go try some ports after that, I still need to let the user know that something like this happened.
I'll post a few more when I come across them. Nope, no port wars between clients here either.
Low speeds due to UDP tracker port *** This bug has been marked as a duplicate of 111127 ***
Forget about it, this torrent uses http trackers
I believe I have figured out what is going wrong here. Joris, the reason why you aren't seeing a problem here is most likely because, as you stated previously, you aren't behind a router. Here's what's going on as far as I can tell. I have ports 45450-45455 set to properly forward from my router to my machine. Ports 45451 is set as the torrent port and 45452 is set as the UDP tracker port in KTorrents preferences. I've noticed long periods of time where the torrents seem to have stalled out. I also noticed that the trackers I use are reporting to me that it appears that I am unconnectable (meaning the ports being used are not forwarded properly) as well as showing that I am using what seemed like random port numbers, all of them firewalled/unconnectable. I decided to put set my machine to the DMZ on the router. (For those that don't know what that means, the router will allow ALL traffic to a machine set up as DMZ, not blocking anything. The router will pass along all traffic to my machine.) I noticed that when I did that, my torrents seriously picked up speed. I took my router off my local network and just plugged my machine into the cable modem with no firewall or iptables running. Again, I would get high and expected speeds. I put the router back on the network and removed my machine from the DMZ and would again notice VERY slow speeds. I ran ktorrent in debug mode and looked at the peers tab and noticed that all the peers or all but one or two peers were marked as snubbed. I put my machine back on DMZ and checked the peers tab again. Almost none were marked as snubbed this time and I was getting much better speeds. Confused about what was going on, I checked netstat -p -l. My output was.. tcp 0 0 *:45451 *:* LISTEN 18321/ktorrent udp 0 0 *:52303 *:* 18321/ktorrent Still shows an incorrect udp port.. strangely enough. I decided to check to see if there was any actual data coming in on 45451 or 52303 with iptraf. Well, it became very clear why things were going on as they were. iptraf was showing that ktorrent had absolutely no incoming data coming in on 45451 whatsoever.. but was sending and receiving on tons of other ports.. ports which are all blocked on my router.. hundreds of different ports instead of the one particular port I set. KTorrent seems to be completely ignoring the port set by the user and is just using what I believe is the default behavior of network programs, asking the OS for the next available port.
The tcp socket is only for accepting new connections (this requires very little data, you will probably only see some data on this port when a new connection is established from the outside world). When a new connection is accepted all data transfers for this connection will go over a randomly chosen port (The OS does this). This is normal behavior.
SVN commit 453499 by guisson: Changes : - Fixing of all speed issues (Bug 111050,Bug 109343) - Bug 111427 (was actually fixed by previous commit, thanks to Ivan) BUG: 111050 BUG: 109343 BUG: 111427 M +4 -4 choker.cpp M +3 -3 choker.h M +5 -5 chunkdownload.cpp M +1 -1 chunkdownload.h M +8 -5 peer.cpp M +4 -1 peer.h M +5 -13 peermanager.cpp M +4 -4 peermanager.h M +2 -2 peeruploader.cpp M +2 -2 peeruploader.h M +1 -1 piece.cpp M +1 -1 piece.h M +1 -1 request.cpp M +5 -5 request.h M +2 -2 torrentcontrol.cpp M +1 -1 uploader.cpp M +2 -2 uploader.h