Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#3507 closed Enhancement (wontfix)

Add ability to ignore certain trackers

Reported by: stephenrs Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.04
Severity: Normal Keywords:
Cc:

Description

Please see https://forum.transmissionbt.com/viewtopic.php?f=4&t=10378&start=0 for history and suggested solutions.

Since tracker.thepiratebay.org resolves to localhost (127.0.0.1) at the DNS level, when Transmission downloads torrents which include this tracker, the result is that a barrage of GET requests are sent to the client webserver while the given torrent is in the torrent list. This causes exceedingly high cpu load on the client machine, sometimes making it unusable for other cpu-needy applications (and renders the localhost webserver effectively crippled for other web apps).

This problem originates outside the scope of Transmission, but T is not doing as much as it could to mitigate it, and is actually exacerbating the problem. Also, there are workaround steps that users can take to address this issue, but either the workarounds require technical knowledge beyond that of the average user, or they turn the usual drag and drop simplicity of T into a multi-step pain.

It would be nice if T could be modified to address this issue out of the box, or at least empower users to do so without messy workarounds.

Change History (5)

comment:1 follow-up: Changed 11 years ago by User294

Only a few people are running web servers on the same machine as transmission and these people are usually advanced enough to workaround things on their own. And only few of them will have issue with CPU when their web server returns something like 404 (not found) error when announce URL was not found as it's not a tracker. What is the strange configuration you're running that returning 404 (not found) errors takes a lot of CPU on server? I'm not a dev, just a curious how you've managed to run into such strange scenario. As a workaround: adding problematic tracker to "hosts" file with another IP probably will solve your problem. This is common method of dealing with DNS quirks. And once OS can handle it (virtually any OS, even Windows), why app should bother itself with same or similar rarely used feature? This will add up some code but almost nobody would benefit from this.

comment:2 in reply to: ↑ 1 Changed 11 years ago by stephenrs

Replying to User294:

Only a few people are running web servers on the same machine as transmission and these people are usually advanced enough to workaround things on their own.

I have no idea how many people have Apache activated on their machines, and neither do you, but since it's built-in to the OS and is dirt simple to turn on, I obviously think this problem is worth some attention.

And only few of them will have issue with CPU when their web server returns something like 404 (not found) error when announce URL was not found as it's not a tracker. What is the strange configuration you're running that returning 404 (not found) errors takes a lot of CPU on server? I'm not a dev, just a curious how you've managed to run into such strange scenario.

The problem is not that "returning 404 errors takes a lot of CPU". The problem is that for a single torrent with a bad tracker inside, Transmission generates literally dozens of requests every SECOND (so imagine what the server load is like when there are multiple torrents with thepireatebay tracker inside [sumotorrent causes the same problem, incidentally]). So, the CPU load is is caused by the web server trying to handle the continuous stream of requests coming from Transmission - it's like a DOS attack on yourself.

Also, there is nothing at all strange about my configuration (and it's a hardware-maxed-out 3 month old MBP), it's a simple config using name based virtual hosting - absolutely anyone with apache running will have exactly the same result (unless they address the problem specifically via conf files). I suspect that others may not notice the problem because they don't know how to inspect cpu usage from the command line, and/or are not using GUI system monitoring tools.

As a workaround: adding problematic tracker to "hosts" file with another IP probably will solve your problem. This is common method of dealing with DNS quirks.

I've already tried this and it hasn't worked. Although I haven't yet investigated why it doesn't work, I suspect that Transmission is either caching DNS internally, or is bypassing the hosts file. So the only workaround I've found so far is to use the inspector to delete the offending trackers, then restart Transmission - a real pain, and not at all sustainable for day to day usage as far as I'm concerned.

And once OS can handle it (virtually any OS, even Windows), why app should bother itself with same or similar rarely used feature? This will add up some code but almost nobody would benefit from this.

I so far have not found a way to handle this at the OS level...maybe I'll configure apache to rewrite these requests to the Transmission site, so folks can see what I mean (just kidding)...and it is my strong opinion that everyone will benefit from making Transmission a better, more bullet-proof piece of software if this flaw is addressed. Although Transmission doesn't cause this easily replicated, well-documented, and easy to address problem, it unnecessarily exacerbates it in an extreme way for at least some users.

The bottom line is that every client installation of Transmission is originating millions of requests that it knows will never receive a successful response. The fact that some of these installations may not be running a webserver I would say is irrelevant. If nothing else, T might perform a little better overall if this was fixed - it's doing unnecessary work, and causing everyone's machines to do the same...not to mention the unnecessary dns lookups and network traffic created by this...

Also, a side effect of this problem is that server log files grow extremely rapidly due to the barrage of requests. This means that for example, if someone wanted to set up a seeder-only machine and put it in a corner and forget about it (without working around this problem in advance), the machine would eventually blow itself up by running out of disk space - even without downloading a single new torrent. This seems problematic to me - because it means that Transmission - completely on it's own - is capable of bringing a computer to its knees under fairly normal circumstances if left running long enough. I can't say that about anything else I have running on my computer. Can you?

Being a software developer myself, I understand that you can't please everyone, so if the devs don't think this is important enough to do something about (and judging from the silence here and on the forum, this appears to be the case), I'll probably just switch to something else when I find time to look around.

Last edited 11 years ago by stephenrs (previous) (diff)

comment:3 Changed 11 years ago by jordan

  • Summary changed from Transmission should be able to ignore certain trackers to Add ability to ignore certain trackers

comment:4 Changed 11 years ago by livings124

  • Resolution set to wontfix
  • Status changed from new to closed

I've re-skimmed this, but I don't see the utility in this. Why not just delete problem trackers? Is this something end-users would use? This seems like a requested hack to get around something that shouldn't be Transmission's problem. I'm going to close this, but please reopen if I'm missing something.

comment:5 Changed 11 years ago by stephenrs

Why not just delete problem trackers?

Yes..figuring out which torrent is causing the problem...then opening the inspector and deleting the bad tracker...then quitting Transmission (and we all know how long that can take)...then restarting Transmission (and hoping that you got all the offending torrents)...can definitely workaround the problem, but is this really the best the T team can offer?

This seems like a requested hack to get around something that shouldn't be Transmission's problem

This is not a hack, it's a suggestion that would make T a better piece of software, because it would infuse the application with an awareness of actual circumstances that exist in the real world - and give users the ability to work around a very real problem without having to go through a 5 minute (or more) tedious exercise (as described above). It's really bizarre to me that folks here keep throwing their hands up in the air and saying "not my problem"...no one has offered any logical reason why Transmission can't include the simple ability to prevent it from wasting CPU cycles and bandwidth when dealing with bogus trackers (and TPB isn't the only one that causes this problem). Why is this any different than throttling ul/dl speed or number of connections, depending on a user's computing environment?

There are a number of ways of approaching this problem...but the first step is acknowledging that it's not inconsistent with the functional goals of the software to actually do something about it...or does the T team think it's a good thing that Transmission launches thousands and thousands of bogus requests to trackers that everyone knows will never respond? WTF?

Maybe it's not a bug, and maybe it "shouldn't be transmission's problem", but when an application originates network/http requests that DIRECTLY CAUSE a computer's CPUs (then fans) to max out for absolutely no good reason, it IS that particular application's problem as far as users are concerned.

Really weird that no one wants to acknowledge Transmission's role in exacerbating a problem that only comes to light WHEN YOU USE THE APPLICATION. In other words, the circumstances that lead to the problem do exist outside of Transmission's scope, but the problem doesn't surface until you actually run Transmission - so T plays a unequivocally direct role.

I think I'll build an app that slowly ramps up to establish as many network connections as it can, then when users are unable to do anything else with their bandwidth while my app is running because their router's max simultaneous connections has been hit, I'll pretend it's the problem of router manufacturers...or tell users to just restart the app every once in a while as an acceptable workaround. Get it?

Oh well, I tried...keep your heads in the mud.

Note: See TracTickets for help on using tickets.