In C tor, we found that it's a good idea for clients to launch multiple initial download attempts in parallel, until they find a circuit that can really give them a consensus. Arti should probably do the same, so that users don't run into the same bootstrapping problems.
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
Here's the idea: right now, when we start from zero trying to download a consensus, we launch a single attempt from a single fallback directory. (The actual launching happens in the tor-dirmgr crate.) Instead we should perhaps launch multiple parallel attempts from different fallbacks. As soon as one starts to give us data, then we can cancel the others.
Our current downloading logic happens from a state machine driver in tor_dirmgr::bootstrap, which asks a state object for a list of document IDs that it's missing, and then tries to find them in the cache, and then tries to download what it's missing. The downloads get launched from the fetch_multiple() function in that module.
I think we'd want to do this change as follows:
Add a new field to DocQuery::LatestConsensus to indicate the desired amount of parallelism. This should probably be 1 if we already have a verified consensus, and a configurable value otherwise.
Have this field get set when DocQuery::LatestConsensus is generated.
Alter query_into_requests so that it marks which request should be attempted in parallel.
Write a function that launches a directory request in parallel to different independent directory caches, waits till one succeeds, and cancels the others. (Perhaps it should cancel the others oncce the first one has reached a given level of completion)
Tie all these functions together, and write a bunch of tests.