Open GoogleCodeExporter opened 9 years ago
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
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
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
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
Original issue reported on code.google.com by
amanotr...@googlemail.com
on 8 Feb 2011 at 4:04