Module tor_netdoc::doc::netstatus

source ·
Expand description

Parsing implementation for networkstatus documents.

In Tor, a networkstatus documents describes a complete view of the relays in the network: how many there are, how to contact them, and so forth.

A networkstatus document can either be a “votes” – an authority’s view of the network, used as input to the voting process – or a “consensus” – a combined view of the network based on multiple authorities’ votes, and signed by multiple authorities.

A consensus document can itself come in two different flavors: a “ns”-flavored consensus has references to router descriptors, and a “microdesc”-flavored consensus has references to microdescriptors.

To keep an up-to-date view of the network, clients download microdescriptor-flavored consensuses periodically, and then download whatever microdescriptors the consensus lists that the client doesn’t already have.

For full information about the network status format, see dir-spec.txt.

§Limitations

NOTE: The consensus format has changes time, using a “consensus-method” mechanism. This module is does not yet handle all all historical consensus-methods.

NOTE: This module does parse some fields that are not in current use, like relay nicknames, and the “published” times on microdescriptors. We should probably decide whether we actually want to do this.

TODO: This module doesn’t implement vote parsing at all yet.

TODO: This module doesn’t implement ns-flavored consensuses.

TODO: More testing is needed!

TODO: There should be accessor functions for most of the fields here. As with the other tor-netdoc types, I’m deferring those till I know what they should be.

Structs§

  • Parts of the networkstatus header that are present in every networkstatus.
  • A single microdescriptor consensus netstatus
  • A builder object used to construct a consensus.
  • The header of a consensus networkstatus.
  • All information about a single authority, as represented in a consensus
  • Description of an authority’s identity and address.
  • The signed footer of a consensus netstatus.
  • The lifetime of a networkstatus document.
  • A single relay’s status, as represented in a microdesc consensus.
  • A set of named network parameters.
  • A single relay’s status, as represented in a “ns” consensus.
  • A list of subprotocol versions that implementors should/must provide.
  • A set of recognized directory flags on a single relay.
  • A Builder object for creating a RouterStatus and adding it to a consensus.
  • A shared-random value produced by the directory authorities, along with meta-information about that value.
  • A shared random value produced by the directory authorities.
  • The signature of a single directory authority on a networkstatus document.
  • A collection of signatures that can be checked on a networkstatus document
  • A Microdesc consensus whose signatures have not yet been checked.

Enums§

  • A recognized ‘flavor’ of consensus document.
  • Keywords that can be used in votes and consensuses.
  • Recognized weight fields on a single relay in a consensus

Traits§

  • Trait to parse a single relay as listed in a consensus document.
  • Represents a single relay as listed in a consensus document.

Type Aliases§

  • A consensus document that lists relays along with their microdescriptor documents.
  • NsConsensusns_consensus
    A consensus document that lists relays along with their router descriptor documents.
  • A Consensus object that has been parsed, but not checked for signatures and timeliness.
  • An MdConsensus that has been parsed but not checked for signatures and timeliness.
  • An NsConsensus that has been parsed but not checked for signatures and timeliness.
  • An MdConsensus that has been parsed and checked for timeliness, but not for signatures.
  • An NsConsensus that has been parsed and checked for timeliness, but not for signatures.