[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [torspec/master] 271: decouple timeout from the rest of UPDATE_WAITING



commit 41082ff32d5b4a0aaa52e63ad9d0bb6fa47e37fd
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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}.



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits