Two tracker errors on multiple torrents

[Mortician]

HI

I've googled around and looked through the FAQ but haven't really found anything relating to my problem.

First off, I can't unblock the UDP listen port which I'm guessing is the reason for the below screen shot "UDP tracker no responce". This happens on all UDP trackers.

I've forwarded my listen port, Disabled my firewall (eset smart security), tried adding exceptions for the port and program, I've tried disabling my router firewall and every single security option it has but nothing has made a difference, UDP just remains blocked.

Listen Port of TCP: 17096 (Opened in Firewall/Router)

Listen Port of UDP: 17096 (Blocked by Firewall/Router)

There's another error which I receieve from non-UDP trackers which you can also see in the screenshot (maybe one tracker won't return this error per torrent), something about the connection being stopped by software on my pc. Like I said above I've tried disabling my firewalls and added rules etc but this also doesn't make a difference. Any idea what kind of program it would be that is 'aborting' the connection or is it my router or something other than my pc when it refers to host machine?

I have only recently started trying to use BitComet instead of uTorrent (4 days or so) and haven't had much luck to be honest. Its taken these 4 days to download 40% of a 500mb file and all my other downloads are stagnant in BitComet while (I was testing last night through a different port which I forwarded for uTorrent) in a few hours with uTorrent I was able to get 60% of the same episode and bitcomet did something like 3%. At the moment I'm getting something like 1-3 (3 is probably the max) seeds on a torrent that can actually connect to a tracker in bitcoment while utorrent got 17+ last night (I even added extra trackers to bitcomet and not utorrent). uTorrent generally replied with 'Connection closed by Peer' while attempting to connect to trackers.

(I'm not trying to say uTorrent is better or anything of the sort I'm just trying to understand why these problems are happening, and how I can fix them with and use your program.)

I'm using Windows 7, Bitcomet ver 1.20, Eset smart security, my isp is South African and is iBurst (wireless).

Thanks

Mortician

Edited April 26, 2010 by Mortician (see edit history)

[kluelos]

Very few trackers use or support UDP. There's no good reason to. Many torrents are nevertheless created with UDP counterparts for trackers that don't support them. Your port is likely open to the protocol but the tracker isn't (& never has) broadcasting it.

You're not missing anything by it. UDP is a one-way protocol, a "broadcast" protocol, that isn't designed for two-way communication like TCP is. Everything you could get via UDP you're already getting through the TCP connection, so fretting about this really is just a waste of your time.

When I create a torrent, nothing stops me from adding a UDP url for a tracker, whether it actually exists or not, whether the tracker actually ever supported UDP or ever has. "But it might", goes the half-formed thought, so I'll add it anyway. The url won't work, and the tracker will never respond to it because, duh, it doesn't support UDP. The url will just hang out there, useless, apparently generating an "error" from the tracker which isn't responding to it and never will.

[Mortician]

Oh okay lol, thanks for the reply and explanation, I just figured that because they were there they would do something (To be honest until using BitComet, or like 2 days ago, I had never noticed there were UDP trackers before... Not sure why :P

Any idea regarding the other problem?

[kluelos]

There's no significant difference among bittorrent clients, which all use the same protocol. The transfer speeds will be the same barring some difference.

The first thing I would try in your shoes is to assign BC the same listen port you've been using for µtorrent. This will work just fine as long as you're not trying to run both at once. What this should establish is that, with a clear listen port, BC will run at the same speed as µtorrent.

Then you can try assigning a different listen port (to one or the other), but the new port must be opened in every firewall you have. Since your connection is wireless, it's likely to be firewalled -- most of them are, not for any good reason, and you may have lucked out. In any case, with BC running, use www.canyouseeme.org to check your listen port. If it gives you any answer except "I can see your service on port xxx", then you're being blocked by some firewall, which you may need to find or discover that you can't change.

[Mortician]

Ok, thanks for reply again. In terms of what you suggested in your last post, the ports are open and not blocked by any firewalls.

Can you tell me what causes the "Connection closed by Peer" errors and as in the original screen shot about the connection being closed by software on my pc? Or what causes others to time out?

[kluelos]

Timeout means what it says, that the tracker did not respond within the allowed two minutes. That usually means it's overloaded. Your client will try again automatically. It may have to do that several times before it gets through.

"Connection closed by peer" is mostly a guess, but most of the time it means that the system hasn't got anything registered to receive traffic for that port, which means there's nothing available to respond, so the system closes the connection. That happens when the web server (for example) crashes. A tracker is basically a web server hooked to a simpleminded application and a database. The better trackers take the web server down if the application crashes, because that means there's nothing for the web server to do except invite hacks.

There's no way for someone out on the net to find out whether this is happening or not, which is what I mean when I say it's a guess. Somebody would have to log into the system and see that the web server was down, check the application log and see that a tracker crash took it down, to know this for certain.