mirrors/arti.git/crates/tor-dirmgr/src/bootstrap.rs, branch arti-v0.5.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.5.02022-06-14T18:10:18ZMake display formats work with older derive_more.2022-06-14T18:10:18ZNick Mathewsonnickm@torproject.org2022-06-14T18:10:18Zurn:sha1:331578d19cf18457f5871966005183a6bda8d374Do not update_progress on load if nothing happened.2022-06-14T13:58:58ZNick Mathewsonnickm@torproject.org2022-06-14T13:58:58Zurn:sha1:660b3104a9780b8c1f7d87d314408a8c3bacb843
If there was no partial information, then calling update_progress
will now report a stall in this case, which is not what we want.
DirMgr: Track errors, stalls, and resets as part of status.2022-06-13T17:58:31ZNick Mathewsonnickm@torproject.org2022-06-13T17:58:31Zurn:sha1:13c152d2ac853296124b898389e550557dde98cc
A "reset" happens whenever we have to start a download attempt over
-- either because we ran out of retries, or we found something wrong
with the consensus after fetching certificates.
An "error" happens when we have a recoverable error from one or more
directory sources.
A "stall" happens whenever a round of downloads or cache loads leads
to no change in the status.
We don't yet use this as part of our status reporting.
Refactor our logic for distinguishing download attempts2022-06-13T17:21:09ZNick Mathewsonnickm@torproject.org2022-06-13T17:21:09Zurn:sha1:2a2afaa7c277da2b2bfe00b65385eeef840fbbde
Previously we used the "if-modified-since" time associated with the
consensus download, and/or the "valid-after" time in the consensus
attempt, to put multiple attempts into sequence, and to tell one
from another. But that approach was always a kludge, and will soon
get more unreliable as the DirStatus logic gets a bit more complex.
With this commit, we change separate download attempts to be
identified with an AttemptId that increments whenever we decide to
get a different directory from the one we have. IMO this new code
is _much_ cleaner.
Refactor most DirStatus users to use DirProgress.2022-06-13T16:22:04ZNick Mathewsonnickm@torproject.org2022-06-13T16:22:04Zurn:sha1:68ea880b84c9aedfc276921675f94a257bcc2556
This is all crate-internal APIs, fortunately.
DirMgr: Refactor bootstrap to use a TaskSchedule for sleeping.2022-06-10T17:59:30ZNick Mathewsonnickm@torproject.org2022-06-07T16:37:12Zurn:sha1:171b406b00d0abef5debbb3b0090dfe881206bac
This change (not yet exposed as an API) will let the TorClient have
a `TaskHandle` corresponding to the directory task, letting it
make the directory task dormant as needed.
DirMgr:: Remove Error::NoChange as redundant.2022-05-25T12:58:37ZNick Mathewsonnickm@torproject.org2022-05-25T12:58:37Zurn:sha1:0caa5bcba5c3be8aca2fb90331a830d1a22f5e22
Now that the relevant functions now report changed/not-changed
status via a boolean out-parameter (see !527), there's no reason to
have a separate NoChanged error case.
Closes #484.
DirMgr: Stop load-from-cache process when there is no change.2022-05-24T12:50:20ZNick Mathewsonnickm@torproject.org2022-05-24T12:50:20Zurn:sha1:8e15c97f56f19ff63cb208f1832827860ad56925
Previously in !511 I had introduced a bug where, if there was an
error more serious than "no change", that error would keep us from
noticing that we had no change, and we'd loop until the safety
counter ran out. Then we'd panic.
This commit fixes the bug by reintroducing the `changed` boolean --
this time as an outparam for the add_from_* methods.
Fixes #482.
Simplify advance and reset functions with mem::replace.2022-05-19T12:09:05ZNick Mathewsonnickm@torproject.org2022-05-19T12:09:05Zurn:sha1:5b5b4bbbea7217969509dd3a20318744ecf247cdExplain why we call update_status unconditionally.2022-05-19T12:04:57ZNick Mathewsonnickm@torproject.org2022-05-19T12:04:57Zurn:sha1:eab0046d0ea87e7d80ff4dadf2e71dc326809521