Fix dht_announce_interval not being followed accurately in some cases #7476
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If I'm understanding the code correctly, announcing to the DHT seems to be done by cycling over all torrents with a delay of
dht_announce_interval / total-number-of-torrents
between each torrent - the idea being that announces are spread out evenly over the entire interval rather than everything being announced to the DHT all at once.The delay between torrents seems to be calculated with a minimum of a single second and is rounded down. Depending on the total number of torrents, this might lead to the actual DHT announce interval being considerably shorter or longer than expected, especially with a larger number of torrents.
For example, the default
dht_announce_interval
of 900s with 451 torrents calculates a 1s delay, taking 451s to cycle through everything, or half as long as expected.If there are more than
dht_announce_interval
torrents, the actual announce interval would be longer than expected. 1800 torrents would take 1800s to cycle through, twice as long as expected by default.This change attempts to address this by calculating the delay between torrents using milliseconds instead of seconds, allowing sub-second delays when needed and preventing rounding issues.