diff options
Diffstat (limited to 'spec/guard-spec/algorithm.md')
| -rw-r--r-- | spec/guard-spec/algorithm.md | 52 |
1 files changed, 26 insertions, 26 deletions
diff --git a/spec/guard-spec/algorithm.md b/spec/guard-spec/algorithm.md index 5e30782..b18803b 100644 --- a/spec/guard-spec/algorithm.md +++ b/spec/guard-spec/algorithm.md @@ -4,7 +4,7 @@ <a id="guard-spec.txt-4.0"></a> -## The guards listed in the current consensus. [Section:GUARDS] +## The guards listed in the current consensus. \[Section:GUARDS\] By {set:GUARDS} we mean the set of all guards in the current consensus that are usable for all circuits and directory @@ -17,7 +17,7 @@ from any guard, so that all guards are usable for all circuits. <a id="guard-spec.txt-4.1"></a> -## The Sampled Guard Set. [Section:SAMPLED] +## The Sampled Guard Set. \[Section:SAMPLED\] We maintain a set, {set:SAMPLED_GUARDS}, that persists across invocations of Tor. It is a subset of the nodes ordered by a sample idx that @@ -130,7 +130,7 @@ adversary node. <a id="guard-spec.txt-4.2"></a> -## The Usable Sample [Section:FILTERED] +## The Usable Sample \[Section:FILTERED\] We maintain another set, {set:FILTERED_GUARDS}, that does not persist. It is derived from: @@ -185,9 +185,9 @@ filtering restrictions that we had in the past. <a id="guard-spec.txt-4.3"></a> -## The confirmed-guard list. [Section:CONFIRMED] +## The confirmed-guard list. \[Section:CONFIRMED\] -[formerly USED_GUARDS] +\[formerly USED_GUARDS\] We maintain a persistent ordered list, {list:CONFIRMED_GUARDS}. It contains guards that we have used before, in our preference @@ -247,7 +247,7 @@ traffic. <a id="guard-spec.txt-4.4"></a> -## The Primary guards [Section:PRIMARY] +## The Primary guards \[Section:PRIMARY\] We keep a run-time non-persistent ordered list of {list:PRIMARY_GUARDS}. It is a subset of {FILTERED_GUARDS}. It @@ -280,7 +280,7 @@ usable after all. <a id="guard-spec.txt-4.5"></a> -## Retrying guards. [Section:RETRYING] +## Retrying guards. \[Section:RETRYING\] (We run this process as frequently as needed. It can be done once a second, or just-in-time.) @@ -303,7 +303,7 @@ now from the fact that it was unreachable a few minutes ago. <a id="guard-spec.txt-4.6"></a> -## Selecting guards for circuits. [Section:SELECTING] +## Selecting guards for circuits. \[Section:SELECTING\] Every origin circuit is now in one of these states: @@ -385,7 +385,7 @@ In some cases (for example, when we need a certain directory feature, or when we need to avoid using a certain exit as a guard), we need to restrict the guards that we use for a single circuit. When this happens, we remember the restrictions that applied when choosing the guard for -that circuit, since we will need them later (see [UPDATE_WAITING].). +that circuit, since we will need them later (see \[UPDATE_WAITING\].). **Rationale** @@ -406,11 +406,11 @@ circuit through each, to give it a chance to succeed or fail. If ever such a circuit succeeds, we don't use it until we're pretty sure that it's the best guard we're getting. (see below). -[XXX timeout.] +\[XXX timeout.\] <a id="guard-spec.txt-4.7"></a> -## When a circuit fails. [Section:ON_FAIL] +## When a circuit fails. \[Section:ON_FAIL\] When a circuit fails in a way that makes us conclude that a guard is not reachable, we take the following steps: @@ -427,17 +427,17 @@ is not reachable, we take the following steps: below.) ``` -[Note: the existing Tor logic will cause us to create more +\[Note: the existing Tor logic will cause us to create more circuits in response to some of these steps; and also see -[ON_CONSENSUS].] +\[ON_CONSENSUS\].\] **Rationale** -See [SELECTING] above for rationale. +See \[SELECTING\] above for rationale. <a id="guard-spec.txt-4.8"></a> -## When a circuit succeeds [Section:ON_SUCCESS] +## When a circuit succeeds \[Section:ON_SUCCESS\] When a circuit succeeds in a way that makes us conclude that a guard _was_ reachable, we take these steps: @@ -466,17 +466,17 @@ guard _was_ reachable, we take these steps: [UPDATE_WAITING] below) ``` -[Note: the existing Tor logic will cause us to create more +\[Note: the existing Tor logic will cause us to create more circuits in response to some of these steps; and see -[ON_CONSENSUS].] +\[ON_CONSENSUS\].\] **Rationale** -See [SELECTING] above for rationale. +See \[SELECTING\] above for rationale. <a id="guard-spec.txt-4.9"></a> -## Updating the list of waiting circuits [Section:UPDATE_WAITING] +## Updating the list of waiting circuits \[Section:UPDATE_WAITING\] We run this procedure whenever it's possible that a `<waiting_for_better_guard>` circuit might be ready to be called @@ -516,9 +516,9 @@ them after all if the `<complete>` circuit goes down before <a id="guard-spec.txt-4.9.1"></a> -### Without a list of waiting circuits [Section:NO_CIRCLIST] +### Without a list of waiting circuits \[Section:NO_CIRCLIST\] -As an alternative to the section [SECTION:UPDATE_WAITING] above, +As an alternative to the section \[SECTION:UPDATE_WAITING\] above, this section presents a new way to maintain guard status independently of tracking individual circuit status. This formulation gives a result equivalent or similar to the approach @@ -540,7 +540,7 @@ these rules: 1. Primary guards are always usable. -2. Non-primary guards are usable _for a given circuit_ if every +1. Non-primary guards are usable _for a given circuit_ if every guard earlier in the preference list is either unsuitable for that circuit (e.g. because of family restrictions), or marked as Unreachable, or has been pending for at least @@ -553,20 +553,20 @@ these rules: Non-primary guards are unusable if they have not become usable after `{NONPRIMARY_GUARD_IDLE_TIMEOUT}` seconds. -3. If a circuit's guard is not usable or unusable immediately, the +1. If a circuit's guard is not usable or unusable immediately, the circuit is not discarded; instead, it is kept (but not used) until the guard becomes usable or unusable. <a id="guard-spec.txt-4.10"></a> -## Whenever we get a new consensus. [Section:ON_CONSENSUS] +## Whenever we get a new consensus. \[Section:ON_CONSENSUS\] We update {GUARDS}. For every guard in {SAMPLED_GUARDS}, we update {IS_LISTED} and {FIRST_UNLISTED_AT}. -[**] We remove entries from {SAMPLED_GUARDS} if appropriate, +\[\*\*\] We remove entries from {SAMPLED_GUARDS} if appropriate, according to the sampled-guards expiration rules. If they were in {CONFIRMED_GUARDS}, we also remove them from {CONFIRMED_GUARDS}. @@ -576,7 +576,7 @@ it, including {USABLE_FILTERED_GUARDS}, and {PRIMARY_GUARDS}. (Whenever one of the configuration options that affects the filter is updated, we repeat the process above, starting at the -[**] line.) +\[\*\*\] line.) ```text 4.11. Deciding whether to generate a new circuit. |