[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