diff options
Diffstat (limited to 'spec/dir-spec/serving-bandwidth-list-files.md')
| -rw-r--r-- | spec/dir-spec/serving-bandwidth-list-files.md | 20 |
1 files changed, 11 insertions, 9 deletions
diff --git a/spec/dir-spec/serving-bandwidth-list-files.md b/spec/dir-spec/serving-bandwidth-list-files.md index 8e7f970..531dc2b 100644 --- a/spec/dir-spec/serving-bandwidth-list-files.md +++ b/spec/dir-spec/serving-bandwidth-list-files.md @@ -4,7 +4,7 @@ If an authority has used a bandwidth list file to generate a vote document it SHOULD make it available at -http://<hostname>/tor/status-vote/next/bandwidth.z +`http://<hostname>/tor/status-vote/next/bandwidth.z` at the start of each voting period. @@ -15,7 +15,7 @@ authorities available. If an authority makes this file available, it MUST be the bandwidth file used to create the vote document available at -http://<hostname>/tor/status-vote/next/authority.z +`http://<hostname>/tor/status-vote/next/authority.z` To avoid inconsistent reads, authorities SHOULD only read the bandwidth file once per voting period. Further processing and serving SHOULD use a @@ -84,7 +84,7 @@ Given a set of votes, authorities compute the contents of the consensus. The consensus status, along with as many signatures as the server currently knows (see section 3.10 below), should be available at -http://<hostname>/tor/status-vote/next/consensus.z +`http://<hostname>/tor/status-vote/next/consensus.z` The contents of the consensus document are as follows: @@ -150,7 +150,7 @@ vote's dir-source line. of the authorities who care about that flag. * Two router entries are "the same" if they have the same - <descriptor digest, published time, nickname, IP, ports> tuple. + (descriptor digest, published time, nickname, IP, ports> tuple. We choose the tuple for a given router as whichever tuple appears for that router in the most votes. We break ties first in favor of the more recently published, then in favor of smaller server @@ -758,14 +758,14 @@ Once an authority has computed and signed a consensus network status, it should send its detached signature to each other authority in an HTTP POST request to the URL: -http://<hostname>/tor/post/consensus-signature +`http://<hostname>/tor/post/consensus-signature` [XXX Note why we support push-and-then-pull.] All of the detached signatures it knows for consensus status should be available at: -http://<hostname>/tor/status-vote/next/consensus-signatures.z +`http://<hostname>/tor/status-vote/next/consensus-signatures.z` Assuming full connectivity, every authority should compute and sign the same consensus including any flavors in each period. Therefore, it @@ -835,11 +835,11 @@ The voting period ends at the valid-after time. If the consensus has been signed by a majority of authorities, these documents are made available at -http://<hostname>/tor/status-vote/current/consensus.z +`http://<hostname>/tor/status-vote/current/consensus.z` and -http://<hostname>/tor/status-vote/current/consensus-signatures.z +`http://<hostname>/tor/status-vote/current/consensus-signatures.z` ```text [XXX current/consensus-signatures is not currently implemented, as it @@ -849,20 +849,22 @@ http://<hostname>/tor/status-vote/current/consensus-signatures.z consensuses.] The other vote documents are analogously made available under -``` http://<hostname>/tor/status-vote/current/authority.z http://<hostname>/tor/status-vote/current/<fp>.z http://<hostname>/tor/status-vote/current/d/<d>.z http://<hostname>/tor/status-vote/current/bandwidth.z +``` once the voting period ends, regardless of the number of signatures. The authorities serve another consensus of each flavor "F" from the locations +``` /tor/status-vote/(current|next)/consensus-F.z. and /tor/status-vote/(current|next)/consensus-F/<FP1>+....z. +``` The standard URLs for bandwidth list files first-appeared in Tor 0.3.5. |