Do not use default tracker interval in tracker_connection::fail

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Add 'unregistered' torrent.
2. Look at tracker interval timeout.

What is the expected output? What do you see instead?
Lower interval.

What version of the product are you using? On what operating system?
0.15.5.0

Please provide any additional information below.
There are a lot of trackers today which use memcached or the like.
That means when a torrent is published via IRC or RSS it is very possible that 
the tracker at that time still has announces cached and will thus answer to the 
first announce with something like "Unregistered torrent" currently this makes 
libtorrent wait for the default tracker interval.

This can be up to 45 minutes, or longer depending on the tracker. Average is 
probably 30 mins.
That is ridicules considering that users who face this issue used some sort of 
mechanism (IRC/RSS) which was explicitly designed to be fast.

The default interval is meant for successful announces not failed ones imo.
I assume the tracker still gets its interval to the client in this case because 
its not offline it just doesn't know the infohash.
This does probably not happen in case of network errors etc because in this 
case the libtorrent default interval is used which is 30 seconds, if I remember 
that right.

torrent::tracker_request_error or tracker_connection::fail should have a 
smarter way of dealing with different kinds of tracker fails.

Original issue reported on code.google.com by amanotr...@googlemail.com on 8 Feb 2011 at 4:04

[GoogleCodeExporter]

It doesn't seem like receiving an error like "unregistered torrent" is 
necessarily a sign that we should announce more often. Can you think of any 
other indicator? Maybe if the torrent is private as well?

Do you know if any other clients deals with this? It seems mainly the 
responsibility of the tracker.

Actually, come to think of it, it sounds like a bad idea to use memcached in 
front of a tracker, it would not build a very evenly connected graph of peers, 
but deliberately build islands.

Original comment by ar...@bittorrent.com on 8 Feb 2011 at 9:38

[GoogleCodeExporter]

I just now tried utorrent and rtorrent (both latest stable).
Utorrent seems to deal with this situation the same way 0.15 libtorrent does, 
meaning it uses the announce interval it received from the tracker.
Rtorrent on the other hand deals with it the same way it does with any other 
error (network etc), defaulting to its 15 or 20 sec interval and dynamically 
increasing this interval on every successive error, or until a successful 
announce was made at which point it starts using the trackers announce interval.
Which is by the way the same way this libtorrent deals with it if you just make 
it ignore the trackers interval in tracker_connection::fail.

Yes most of these problems occur when the private flag is set. Almost all of my 
torrents have this set though, so I am a poor point of reference.
I assume however that this issue is probably more or less unique to the private 
tracker world. They are the only platform, I know of, that provides mechanisms 
which allow a user to have new torrents pushed to them (via announce bot for 
example). Most other places use pull methods like RSS. Even if these sites 
would experience some kind of caching delay on the tracker, the time frame 
between RSS updates will be enough for most users not to notice this problem.

I also want to add that I am not entirely sure this is a memcached issue. But 
since the trackers I know where this happens all use the same framework and the 
only relevant caching facility I know of there is memcached I immediately 
jumped to it as the probable cause of this problem. Upon further reflection 
now, I would have to say its probably not memached (alone) though. Most likely 
its xbt which, as far as I know, periodically pulls data from the underlying db 
this might be where memcached comes into play or not. I am really not an expert 
here... however the issue remains the same. And its likely to increase because 
said tracker framework (gazelle) is becoming increasingly popular. As to why 
these kinds of trackers cache so excessively, they god limited funds and thus 
limed hardware - caching the hell out of everything is most likely the only way 
to keep things running.

Original comment by amanotr...@googlemail.com on 8 Feb 2011 at 9:41

[GoogleCodeExporter]

Yeah, it doesn't necessarily mean it's being cached. It could just be delay of 
ingesting the new info-hash into the DB, or as you say, xbt rate limiting how 
often it polls the database.

I'm a little bit hesitant to change the default behavior of tracker errors. The 
current behavior is actually a feature to give trackers more power over client 
retry intervals. However, I'm not opposed to having an option to treat tracker 
error messages as any other tracker error (i.e. ignore the interval). There's a 
theoretical DDoS attack by inserting a victim as a tracker in a very popular 
torrent. With this feature, at least the victim can tell all users to never 
come back (essentially).

Do you know if anyone has contacted the gazelle devs telling them about this 
issue? One simple fix for them would be to lower the retry interval returned in 
this error message, or, maybe a more proper fix, to make sure the tracker is 
up-to-date before announcing the torrent over IRC.

Original comment by ar...@bittorrent.com on 9 Feb 2011 at 4:41

[GoogleCodeExporter]

I will try to contact the gazelle devs about this issue and relay the answer 
here.

The longer I think about this, the better I can understand your position here. 
I mean ignoring the tracker would take away control from the tracker admins and 
that is clearly not desirable for either side.
On the other hand I can understand the tracker admins and gazelle devs, 
lowering the interval on this specific error puts them in a position where a 
client might hammer them because its exactly doing what the tracker told it to 
do. Torrents are deleted all the time because of various reasons and that leads 
to the exact same error.
One viable solution could be to dynamically increase this interval (just like 
clients do) which would put more strain on the tracker.
In the end this misbehavior is in no way caused by the client and it only 
effects a very small fraction of its users.

On a personal note I would like to thank you for creating libtorrent and 
especially for taking such good and reliable care of this project.
Thank you!

Original comment by amanotr...@googlemail.com on 9 Feb 2011 at 6:17