Jump to content

µTorrent 2.0.4 released


Firon

Recommended Posts

  • Replies 275
  • Created
  • Last Reply

Top Posters In This Topic

Build 21586: I've seen a few tracker timeouts here too, and also in one of the previous 2.04 builds (think it was 21515). They went away after a while. Only torrents I currently have are from private trackers, if that matters.

I really didn't pay much attention, since I thought they were just tracker glitches, but they might have been the same issue a couple of other people have reported.

Link to comment
Share on other sites

As I posted here 10 minutes ago - http://forum.utorrent.com/viewtopic.php?id=83092 - quoting myself:

After 2.0.4 came out we noticed that our tracker suddenly spiked the load from usual 25-30% to 100% load (that's 2 x Quad Core Xeons 2.4 GHz), announce started to get more requests by a factor of 10 if not even more. Future investigation showed (by logging requests and other activities) that all requests witch fail with an error like "Torrent is not registered with tracker" or 50x errors are repeated by the uTorrent instantly! I logged some ips requests to get detailed stats to comfirm that - clients where sending a request every second.

To completly confirm that, I just downloaded a torrent from my tracker and added it to the uTorrent. Because my tracker is now under extreme load I get 502 error and uTorrent just repeats the request instantly in a loop of "request => 50x => request => 50x => .....".

Please fix that ASAP.

I confirm Psihius's comments about the huge traffic spike hitting the trackers.

This is our traffic graph for the last days:

http://img717.imageshack.us/img717/9905/hwgraphphp.png

This aggregates both the front-end/web interface trafic and the back-end/tracker trefic. Blue is incoming, green is outgoing.

As you can see, we went from a regular, mostly upstream web host, to having the upstream comparable with the downstream because of the bogus requests. The incoming traffic trebled. The outgoing traffic increased moderately because it was high from the regular load (forums, torrent downloads etc.) and the reply from the tracker is very short: "HTTP/1.0 200 OK\r\n\r\nd14:failure reason20:unregistered torrente"

I went ballistic when I saw this, thought we were attacked :). A trafic dump showed allot of "unregistered torrent" queries, all coming from uTorrent 2.0.4 clients, and a Google search later here I am.

Fortunately, our tracker is not PHP based, but a much more capable compiled daemon, that can still handle the load with a ~ 15% CPU usage.

Link to comment
Share on other sites

I had 21515 and now 21586 and the survey links are still here :(

============

-- 2010-08-26: Version 2.0.4 (build 21515)

- Fix: make survey links never show up on XP

- Fix: started and stopped events now correctly sent to torrents with multiple tracker tiers. ============

Link to comment
Share on other sites

and the survey links are still here

On XP / SP? ?

I simply don't understand this - how hard can it be to simply comment that whole code section in the client ? Stop messing with OS related conditional statements :( You fail ... :P

Link to comment
Share on other sites

Did some more testing w/ v2.04 21586. I HAD disabled bandwidth management uTP in v2.0.3 because it was slowing the torrents. It was a long running, 10GB torrent.

Anyhow, I enabled bandwidth management, which made it run faster again, and after about an hour or so, I again diabled bandwidth managent and everything is fine now.

I'm just wondering as to why I must start my torrents w/ bandwidth management enabled, & after awhile disable it to have good torrent performance which almost saturates my connection? Can others replicate this?

Link to comment
Share on other sites

I've stepped back to 2.0.3.21177 and it's solved all the problems of 2.0.4.21586. The afore-mentioned tracker problems, internet shutdowns... it's kind of a mess. One thing I noticed was if the torrent has the following tracker list (for example):

http://tracker.openbittorrent.com:80/announce

udp://tracker.openbittorrent.com:80/announce

udp://tracker.publicbt.com:80/announce

http://tracker.publicbt.com:80/announce

http://genesis.1337x.org:1337/announce

Then the only trackers that'll show up in uTorrent's tracker tab are:

http://tracker.openbittorrent.com:80/announce

udp://tracker.publicbt.com:80/announce

http://genesis.1337x.org:1337/announce

That is, the spaceless (same machine) trackers only show up as the first line in the group. They all show up (properly) in 2.0.3.

Link to comment
Share on other sites

Then the only trackers that'll show up in uTorrent's tracker tab are:

http://tracker.openbittorrent.com:80/announce

udp://tracker.publicbt.com:80/announce

http://genesis.1337x.org:1337/announce

That is, the spaceless (same machine) trackers only show up as the first line in the group. They all show up (properly) in 2.0.3.

That's working as designed in v2.0.4 -- trackers on the same tier should only show the active tracker from that tier in the tracker window/tab.

Torrents shouldn't be spamming updates to lots of trackers every time.

I've used v2.0.3 as well and it handles tracker display the same way as v2.0.4 in tracker window/tab.

Link to comment
Share on other sites

I've stepped back to 2.0.3.21177 and it's solved all the problems of 2.0.4.21586

And created the problem of you being wide open for the major exploit fixed in 2.0.4

i rather have a good old ver than a screwup latest ver........double stepped back to 1.8.5 17414 ver., until utp show it's promises. for now, it's crappy.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...