commit 41082ff32d5b4a0aaa52e63ad9d0bb6fa47e37fd Author: Nick Mathewson <nickm@torproject.org> Date: Thu Dec 8 10:29:00 2016 -0500 271: decouple timeout from the rest of UPDATE_WAITING --- proposals/271-another-guard-selection.txt | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/proposals/271-another-guard-selection.txt b/proposals/271-another-guard-selection.txt index 0f9328f..83f624d 100644 --- a/proposals/271-another-guard-selection.txt +++ b/proposals/271-another-guard-selection.txt @@ -545,10 +545,6 @@ Status: Open * There is no circuit C2 that "blocks" C1. Then, upgrade C1 to <complete>. - * If any circuit stays is <waiting_for_better_guard> - for more than {NONPRIMARY_GUARD_IDLE_TIMEOUT} seconds, - time it out. - Definition: In the algorithm above, C2 "blocks" C1 if: * C2 obeys all the restrictions that C1 had to obey, AND * C2 has higher priority than C1, AND @@ -556,6 +552,12 @@ Status: Open or C2 has been <usable_if_no_better_guard> for no more than {NONPRIMARY_GUARD_CONNECT_TIMEOUT} seconds. + We run this procedure periodically: + + * If any circuit stays is <waiting_for_better_guard> + for more than {NONPRIMARY_GUARD_IDLE_TIMEOUT} seconds, + time it out. + **Rationale** If we open a connection to a guard, we might want to use it @@ -569,7 +571,6 @@ Status: Open them after all if the <complete> circuit goes down before {NONPRIMARY_GUARD_IDLE_TIMEOUT} seconds. - 3.10. Whenever we get a new consensus. [Section:ON_CONSENSUS] We update {GUARDS}.