Repository navigation
Work around bad traffic accounting in trackers #9
Description
Traffic accounting in bittorrent trackers is a hacky mess and has a tendency to break.
One series of events that has been observed to cause issues is this:
- peer_id=1, event=started, downloaded=0
- peer_id=1, event="", downloaded=5
- peer_id=1, event=completed, downloaded=10
- a day of no internet connectivity while the client continues to run
- peer_id=1, event="", downloaded=10
Some trackers seem to interpret event 5 as a new download, with 10 bytes downloaded, causing a total of 20 bytes downloaded across two downloads.I don't know why they would do that, as opposed to rejecting the announce since, if the previous session has timed out, there is no matching event=started announce, but it's the only explanation I could come up with for behavior I have observed, where a multi-hour internet outage resulted in doubled download stats.
We should probably stop retrying announces after a while and consider the session closed. The next announce, then, would be a new event=started announce, with downloaded=0. This will cause us to under-report some downloaded, but only the amount between the last successful announce and last failed announce. This will generally be much less than what we can over-report, namely the entire torrent.
We might also want to immediately stop and then start a torrent that has finished downloading, to ensure a fresh session with downloaded=0.
Activity
dominikh commentedon Sep 17, 2021
From the UNIT3D tracker: https://github.com/HDInnovations/UNIT3D-Community-Edition/blob/7d85d161d3f0fc9 48C5 8788ab9171830c99c74f945fb/app/Jobs/ProcessBasicAnnounceRequest.php#L66-L94
Which suggests to me that this can in fact happen, if there is no "history record". Do history records get deleted after a while?