diff options
author | Nick Mathewson <nickm@torproject.org> | 2023-10-14 14:07:40 -0400 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2023-10-14 14:07:40 -0400 |
commit | 4ba45dfd9afd08edeb46243127a480f1d23b9640 (patch) | |
tree | 4dcdb3b4ac378b255d8292693ef234100bf67ac5 /spec/path-spec | |
parent | d4b9bcc71565e1c3b7b74ddfcd44730697c10c6b (diff) | |
download | torspec-4ba45dfd9afd08edeb46243127a480f1d23b9640.tar.gz torspec-4ba45dfd9afd08edeb46243127a480f1d23b9640.zip |
Run mdformat on the spec files.
Diffstat (limited to 'spec/path-spec')
-rw-r--r-- | spec/path-spec/attaching-streams-to-circuits.md | 4 | ||||
-rw-r--r-- | spec/path-spec/general-operation.md | 2 | ||||
-rw-r--r-- | spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md | 6 | ||||
-rw-r--r-- | spec/path-spec/old-notes.md | 10 |
4 files changed, 11 insertions, 11 deletions
diff --git a/spec/path-spec/attaching-streams-to-circuits.md b/spec/path-spec/attaching-streams-to-circuits.md index e03414e..585885b 100644 --- a/spec/path-spec/attaching-streams-to-circuits.md +++ b/spec/path-spec/attaching-streams-to-circuits.md @@ -6,7 +6,7 @@ When a circuit that might support a request is built, Tor tries to attach the request's stream to the circuit and sends a BEGIN, BEGIN_DIR, or RESOLVE relay cell as appropriate. If the request completes unsuccessfully, Tor -considers the reason given in the CLOSE relay cell. [XXX yes, and?] +considers the reason given in the CLOSE relay cell. \[XXX yes, and?\] After a request has remained unattached for SocksTimeout (2 minutes by default), Tor abandons the attempt and signals an error to the @@ -14,6 +14,6 @@ client as appropriate (e.g., by closing the SOCKS connection). XXX Timeouts and when Tor auto-retries. -* What stream-end-reasons are appropriate for retrying. +- What stream-end-reasons are appropriate for retrying. If no reply to BEGIN/RESOLVE, then the stream will timeout and fail. diff --git a/spec/path-spec/general-operation.md b/spec/path-spec/general-operation.md index e1632af..7127fee 100644 --- a/spec/path-spec/general-operation.md +++ b/spec/path-spec/general-operation.md @@ -23,7 +23,7 @@ as indicated above. When bootstrap completes, Tor will be ready to handle an application requesting an internal circuit to hidden services at ".onion" addresses. -If a future consensus contains Exits, exit circuits may become available.] +If a future consensus contains Exits, exit circuits may become available.\] When a client application creates a new stream (by opening a SOCKS connection or launching a resolve request), we attach it to an appropriate diff --git a/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md b/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md index 06f6914..939f3a2 100644 --- a/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md +++ b/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md @@ -77,7 +77,7 @@ To avoid ln(1.0+epsilon) precision issues, use log laws to rewrite the estimator for 'alpha' as the sum of logs followed by subtraction, rather than multiplication and division: -alpha = n/(Sum_n{ln(MAX(Xm, x_i))} - n*ln(Xm)) +alpha = n/(Sum_n{ln(MAX(Xm, x_i))} - n\*ln(Xm)) In this, n is the total number of build times that have completed, x_i is the ith recorded build time, and Xm is the modes of x_i as above. @@ -133,9 +133,9 @@ other lengths, the client multiples the timeout_ms and close_ms values by a scaling factor determined by the number of communication hops needed to build their circuits: -timeout_ms[hops=n] = timeout_ms * Actions(N) / Actions(3) +timeout_ms\[hops=n\] = timeout_ms * Actions(N) / Actions(3) -close_ms[hops=n] = close_ms * Actions(N) / Actions(3) +close_ms\[hops=n\] = close_ms * Actions(N) / Actions(3) where Actions(N) = N * (N + 1) / 2. diff --git a/spec/path-spec/old-notes.md b/spec/path-spec/old-notes.md index 34734fb..ce3ec44 100644 --- a/spec/path-spec/old-notes.md +++ b/spec/path-spec/old-notes.md @@ -26,15 +26,15 @@ How to deal with network down. circuit and beginning to use it immediately?) ``` -[Do we actually do any of the above? If so, let's spec it. If not, let's -remove it. -NM] +\[Do we actually do any of the above? If so, let's spec it. If not, let's +remove it. -NM\] <a id="path-spec.txt-X.2"></a> ## A thing we could do to deal with reachability And as a bonus, it leads to an answer to Nick's attack ("If I pick -my helper nodes all on 18.0.0.0:*, then I move, you'll know where I +my helper nodes all on 18.0.0.0:\*, then I move, you'll know where I bootstrapped") -- the answer is to pick your original three helper nodes without regard for reachability. Then the above algorithm will add some more that are reachable for you, and if you move somewhere, it's more @@ -59,5 +59,5 @@ our location (IP? subnet?) changes, we have two bad options. We could nasty, since it would force us to record where we've been. ``` -[Do we do any of this now? If not, this should move into 099-misc or -098-todo. -NM] +\[Do we do any of this now? If not, this should move into 099-misc or +098-todo. -NM\] |