[tor-commits] [torspec/main] Describe reload behavior of path-spec data.

[nickm at torproject.org]

commit de373736ee74a300f68e1355e0cbeed812ca5d80
Author: Nick Mathewson <nickm at torproject.org>
Date:   Fri Aug 27 11:04:22 2021 -0400

    Describe reload behavior of path-spec data.
---
 path-spec.txt | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/path-spec.txt b/path-spec.txt
index f257e86..0243260 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -423,9 +423,9 @@ of their choices.
    or network change (see section 2.4.5 below).
 
    Timeouts are stored on disk in a histogram of 10ms bin width, the same
-   width used to calculate the Xm value above. This histogram must be shuffled
-   after being read from disk, to preserve a proper expiration of old values
-   after restart.
+   width used to calculate the Xm value above. The timeouts recorded in the
+   histogram must be shuffled after being read from disk, to preserve a
+   proper expiration of old values after restart.
 
    Thus, some build time resolution is lost during restart. Implementations may
    choose a different persistence mechanism than this histogram, but be aware
@@ -534,6 +534,13 @@ of their choices.
    If the timeout was already at least `cbtinitialtimeout`,
    the client doubles the timeout.
 
+   The records here (of how many circuits succeeded or failed among the most
+   recent 'cbrrecentcount') are also stored as persistent state.  On reload,
+   the history here is reconstructed from the counts by placing successes and
+   failures in an arbitrary order.  (The C Tor implementation shuffles them,
+   whereas Arti always places failures before successes so that they expire
+   sooner.)
+
 2.4.6. Consensus parameters governing behavior
 
    Clients that implement circuit build timeout learning should obey the