Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4527 closed Enhancement (invalid)

'tracker id' should be cached

Reported by: reardon Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.33
Severity: Normal Keywords:
Cc:

Description

the 'tracker id' response to an announce should be cached, saved in .resume, and reloaded on startup.

I haven't looked exhaustively, but I haven't seen an argument against treating the 'tracker id' response as a long-lived value.

The benefit will be mostly with private trackers that use this as a means of tracking. I know of at least two trackers that appear to use this as a means of limiting clients to one instance/location.

Change History (5)

comment:1 Changed 10 years ago by jordan

I'm not sure that I see the benefit in caching this value. Could you discuss this in more detail? Are you saying that caching this value will help you to bypass the one instance/location limit?

comment:2 Changed 10 years ago by reardon

Currently, if I stop/start transmission then on each restart I get banned by certain trackers for some period of time. But if I merely stopped and restart a torrent, no ban. This is because the '&torrentid=' is still available to the existing session and is sent on torrent-start, but is not available when the daemon is just initializing. It should be in long-term cache.

comment:3 Changed 10 years ago by reardon

Just making sure that my last comment is clear: I don't want transmission to do anything to work around tracker limits, but rather to properly present itself to trackers so that a recreated local process (eg after a crash) is treated by the tracker as one session, not a second session.

comment:4 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from new to closed
  • Type changed from Bug to Enhancement

I don't know of any other clients that cache this between sessions.

I also suspect this change could cause problems that are worse than the one that this change would address -- for example, what happens if trackers aren't written to handle an expired, days-old (or weeks-old) tracker id being sent?

Thank you for the suggestion but I'm going to pass on this one.

comment:5 Changed 10 years ago by reardon

This is not a high priority issue.

That said, I don't understand your argument. Transmission already does exactly what you fear: if I pause a torrent for several weeks and then restart that torrent (given the robustness of transmission, I rarely restart the daemon ) , transmission will present the 'old' trackerid to the tracker. You can't have the argument both ways. If you believe your scenario is bad, then you must implement a timeout mechanism for trackerid's so they don't get reused after some arbitrary period.

So, what's the difference between the scenario just described, which is real and happens regularly, and the one I described previously, where transmission has either crashed and or been taken down and then restarted?

Note: See TracTickets for help on using tickets.