From 3af4bf15995be50deaef7ced0d0e0fdc2fc35ba5 Mon Sep 17 00:00:00 2001 From: Dirk Engling Date: Thu, 5 Nov 2026 18:19:42 +0100 Subject: Document the reasoning behind the udp not sending an error packet on blacklisted torrents --- DESIGN | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'DESIGN') diff --git a/DESIGN b/DESIGN index 323a753..d365fb5 100644 --- a/DESIGN +++ b/DESIGN @@ -81,6 +81,25 @@ finish a sweep in OT_CLEAN_INTERVAL_MINUTES. At the default bucket count that is one bucket every 117 ms. +A refused announce is answered over UDP with a well formed announce for an +empty swarm rather than with the error action. BEP 15 binds a client to the +interval it is handed and says nothing about what a client should do with an +error, so an error puts the client on its own retry schedule instead. Over +five minutes against one blacklisted torrent, libtorrent 2.0.8 sent seven +connects and three announces to a tracker answering with the error and two of +each to one answering with an empty swarm, and was still going on a widening +backoff. Transmission 3.00 retries twenty seconds after an error, then at +five, fifteen, thirty, sixty and finally every hundred and twenty minutes. +That last figure sets OT_CLIENT_REJECT_INTERVAL: at anything under two hours +Transmission's own backoff would be the cheaper of the two in steady state. +Neither client bounds a tracker's interval from above, and libtorrent clamps +it from below at five minutes. + +The reject interval is a constant and not a config entry, because the +ordinary announce interval is a constant too and an operator has nothing to +measure a different value against. Over HTTP a refusal stays a failure +reason, which is the only place a user is told why. + Startup and teardown order -------------------------- -- cgit v1.3