diff options
Diffstat (limited to 'spec/guard-spec/algorithm.md')
| -rw-r--r-- | spec/guard-spec/algorithm.md | 26 |
1 files changed, 13 insertions, 13 deletions
diff --git a/spec/guard-spec/algorithm.md b/spec/guard-spec/algorithm.md index acdf343..0f04f31 100644 --- a/spec/guard-spec/algorithm.md +++ b/spec/guard-spec/algorithm.md @@ -157,7 +157,7 @@ of the following are true: We have an additional subset, {set:USABLE_FILTERED_GUARDS}, which is defined to be the subset of {FILTERED_GUARDS} where -{is_reachable} is <yes> or <maybe>. +{is_reachable} is `<yes>` or `<maybe>`. We try to maintain a requirement that {USABLE_FILTERED_GUARDS} contain at least {MIN_FILTERED_SAMPLE} elements: @@ -278,13 +278,13 @@ usable after all. (We run this process as frequently as needed. It can be done once a second, or just-in-time.) -If a primary sampled guard's {is_reachable} status is <no>, then -we decide whether to update its {is_reachable} status to <maybe> +If a primary sampled guard's {is_reachable} status is `<no>`, then +we decide whether to update its {is_reachable} status to `<maybe>` based on its {last_tried_connect} time, its {failing_since} time, and the {PRIMARY_GUARDS_RETRY_SCHED} schedule. -If a non-primary sampled guard's {is_reachable} status is <no>, then -we decide whether to update its {is_reachable} status to <maybe> +If a non-primary sampled guard's {is_reachable} status is `<no>`, then +we decide whether to update its {is_reachable} status to `<maybe>` based on its {last_tried_connect} time, its {failing_since} time, and the {GUARDS_RETRY_SCHED} schedule. @@ -306,9 +306,9 @@ Every origin circuit is now in one of these states: <state:complete>. ``` -You may only attach streams to <complete> circuits. +You may only attach streams to `<complete>` circuits. (Additionally, you may only send RENDEZVOUS cells, ESTABLISH_INTRO -cells, and INTRODUCE cells on <complete> circuits.) +cells, and INTRODUCE cells on `<complete>` circuits.) The per-circuit state machine is: @@ -468,8 +468,8 @@ See [SELECTING] above for rationale. ## 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 -<complete>. +`<waiting_for_better_guard>` circuit might be ready to be called +`<complete>`. ```text * If any circuit C1 is <waiting_for_better_guard>, AND: @@ -498,9 +498,9 @@ immediately (if we're sure that it's the best we can do), or we might want to wait a little while to see if some other circuit which we like better will finish. -When we mark a circuit <complete>, we don't close the +When we mark a circuit `<complete>`, we don't close the lower-priority circuits immediately: we might decide to use -them after all if the <complete> circuit goes down before +them after all if the `<complete>` circuit goes down before {NONPRIMARY_GUARD_IDLE_TIMEOUT} seconds. <a id="guard-spec.txt-4.9.1"></a> @@ -574,8 +574,8 @@ We generate a new circuit when we don't have enough circuits either built or in-progress to handle a given stream, or an expected stream. -For the purpose of this rule, we say that <waiting_for_better_guard> -circuits are neither built nor in-progress; that <complete> +For the purpose of this rule, we say that `<waiting_for_better_guard>` +circuits are neither built nor in-progress; that `<complete>` circuits are built; and that the other states are in-progress. ```text |