search

dominikh / gamayun

Torrent client designed for seeding tens of thousands of torrents.
MIT License
14 stars 0 forks source link

Work around bad traffic accounting in trackers #9

Open dominikh opened 2 years ago

dominikh commented 2 years ago

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:

  1. peer_id=1, event=started, downloaded=0
  2. peer_id=1, event="", downloaded=5
  3. peer_id=1, event=completed, downloaded=10
  4. a day of no internet connectivity while the client continues to run
  5. 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.

dominikh commented 2 years ago

From the UNIT3D tracker: https://github.com/HDInnovations/UNIT3D-Community-Edition/blob/7d85d161d3f0fc98788ab9171830c99c74f945fb/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?