Function tor_netdir::testnet::construct_custom_network

pub fn construct_custom_network<F>(
    func: F,
    lifetime: Option<Lifetime>
) -> BuildResult<(MdConsensus, Vec<Microdesc>)>
where
    F: FnMut(usize, &mut NodeBuilders),

Available on crate feature testing only.

Build a fake network with enough information to enable some basic tests.

By default, the constructed network will contain 40 relays, numbered 0 through 39. They will have with RSA and Ed25519 identity fingerprints set to 0x0000…00 through 0x2727…27. Each pair of relays is in a family with one another: 0x00..00 with 0x01..01, and so on.

All relays are marked as usable. The first ten are marked with no additional flags. The next ten are marked with the exit flag. The next ten are marked with the guard flag. The last ten are marked with the exit and guard flags.

TAP and Ntor onion keys are present, but unusable.

Odd-numbered exit relays are set to allow ports 80 and 443 on IPv4. Even-numbered exit relays are set to allow ports 1-65535 on IPv4. No exit relays are marked to support IPv6.

Even-numbered relays support the DirCache=2 protocol.

Every relay is given a measured weight based on its position within its group of ten. The weights for the ten relays in each group are: 1000, 2000, 3000, … 10000. There is no additional flag-based bandwidth weighting.

The consensus is declared as using method 34, and as being valid for one day (in realtime) after the current SystemTime.

Customization

Before each relay is added to the consensus or the network, it is passed through the provided filtering function. This function receives as its arguments the current index (in range 0..40), a RouterStatusBuilder, and a MicrodescBuilder. If it returns a RouterStatusBuilder, the corresponding router status is added to the consensus. If it returns a MicrodescBuilder, the corresponding microdescriptor is added to the vector of microdescriptor.

Notes for future expansion

Resist the temptation to make unconditional changes to this function. If the network generated by this function gets more and more complex, then it will become harder and harder over time to make it support new test cases and new behavior, and eventually we’ll have to throw the whole thing away. (We ran into this problem with Tor’s unit tests.)

Instead, refactor this function so that it takes a description of what kind of network to build, and then builds it from that description.