| Summary: | UDP Tracker Port Option Not Working | ||
|---|---|---|---|
| Product: | [Applications] ktorrent | Reporter: | Jason Carter <darkstalker> |
| Component: | general | Assignee: | Joris Guisson <joris.guisson> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Torrent which uses UDP trackers | ||
|
Description
Jason Carter
2005-08-20 03:58:52 UTC
Also, the trackers are showing me as using port 0 for some reason. And I was thinking about releasing a 1.1 beta ... Yeah the speed problems can probably be attributed to this : - You send your announce, but you never get reply back, which means you get no list of peers to connect to - Seeing that the tracker knows you, other people connect to you through the properly forwarded TCP port You obviously are going to get low speeds because of this. Port changes only take effect when you restart KTorrent, you can't switch ports in the middle of a download. *** Bug 111050 has been marked as a duplicate of this bug. *** "Port changes only take effect when you restart KTorrent, you can't switch ports in the middle of a download." I wasn't expecting the port changes to take effect in the middle of a download, but it would be nice for it to take effect right away if no torrents are currently active though. Notification that the port change will only take effect once KTorrent is restarted, or when all torrents are stopped (if you decide to implement it) would be good as well. KTorrent listens to the correct ports : I put my ports on 6881 (for tcp) and 7000 (udp tracker port) tcp 0 0 0.0.0.0:6881 0.0.0.0:* LISTEN 10664/ktorrent udp 0 0 0.0.0.0:7000 0.0.0.0:* 10664/ktorrent I did fix a serious bug in the UDP Tracker. Which is probably the cause of the speed issues. Post a link to the torrent, if the torrent doesn't use UDP trackers, normally no UDP ports will be created. Wait a second, the UDP port will only be created when the tracker of a torrent uses UDP, so if you startup you should only see a TCP port. Created attachment 12275 [details]
Torrent which uses UDP trackers
Try this torrent which uses UDP trackers, after you open it, run netstat.
tcp 0 0 *:45451 *:* LISTEN 30059/ktorrent udp 0 0 *:45452 *:* 30059/ktorrent udp 0 0 *:41079 *:* 30059/ktorrent No idea why there's an extra one on the list. When I first added the UDP torrent, I already had two that jumped up and started going on their own because I had restarted the program.. so maybe that's why this looks a little different. Anyways, this is after just restarting the program with ONLY that UDP torrent you sent. These are the ports you selected ? (ignoring the phantom port) Yes, 45451 and 45452 are the selected ports. Also, it seems the ports are opened even if there are no torrents listed in ktorrent at all. Yeah the TCP one is open all the time. Bug closed, there was no bug. What about the UDP phantom port that also always seems open and isn't the same as the selected UDP tracker port? Separate bug? Ports just don't get opened by accident, so it must be something in the KDE libs which is opening the port. I don't seem to get this phantom port. Maybe a port used by KHTML to do DNS lookups ? DNS operates over UDP, and if you search something KHTML will have to lookup the IP address of it. But this is just a guess. Read comment #5 on http://bugs.kde.org/show_bug.cgi?id=111050. I believe this is the same problem. So why did you reopen both bugs? This one seems to be fixed. The "phantom port" is actually the one Qt creates for DNS. If Joris were using the KDE API, that port wouldn't show. Well I tried to switch to the KDE api, but it only resulted in crashes inside the KDE api. Then a whole bunch of bugs where reported, so I dealt with those first. Bug closed. |