1 files changed, 19 insertions, 0 deletions

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
 --------------------------