mirrors/arti.git/crates/tor-guardmgr/src/sample.rs, branch arti-v0.4.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.4.02022-04-07T20:01:46ZInitial functions to determine and expose a clock skew estimate.2022-04-07T20:01:46ZNick Mathewsonnickm@torproject.org2022-04-07T16:16:13Zurn:sha1:eedee51899eb3365a21c37be3803846373265284
(This is just a placeholder; I'm going to make the functions
smarter in the next commit.)
GuardMgr: record clock skew information.2022-04-07T15:33:34ZNick Mathewsonnickm@torproject.org2022-04-07T15:30:08Zurn:sha1:99146da2c2654c01259b8219bd491c5d4ac47039
(It is not yet actually used.)
GuardMgr: Tests for copy_status_from.2022-04-05T14:36:29ZNick Mathewsonnickm@torproject.org2022-04-05T14:36:29Zurn:sha1:fe43f0ddb5463e5f1a9c780924d1002de3958045Rewrite and fix Guard::copy_status_from.2022-04-05T13:37:44ZNick Mathewsonnickm@torproject.org2022-04-05T13:37:44Zurn:sha1:3ba9b47000103ac9ab3f2d5d8f75e51059b70f01
The old version of this function was error-prone, and in fact had
errors: it was too easy to forget to add non-persistent fields, and
that's exactly what we forgot in a few cases
(`microdescriptor_missing`, `circ_history`, and
`suspicious_behavior_warned`).
The new version of this function consumes both of the incoming
Guards, and constructs every field explicitly so that we can't
forget to list any.
Closes #429.
GuardMgr: Track directory status and circuit status separately.2022-04-05T13:18:04ZNick Mathewsonnickm@torproject.org2022-04-04T19:41:28Zurn:sha1:b3e06b93b6a34922cd8d07f13aa8f265ae7e8af3
Previously, we treated successfully building a circuit to a guard as
a "success", and any failure, including a directory cache failure,
as a failure. With this change, guards now have separate
success/failure and retry status for circuit usage and directory
usage.
This change is needed for guard-as-directory retry to have
reasonable behavior. Otherwise, when a guard succeeds at building a
circuit, that clears the directory-is-failing status and makes us
retry the guards to quickly.
Refactor FirstHopId into type-differentiated form2022-03-30T14:41:39ZNick Mathewsonnickm@torproject.org2022-03-29T14:55:20Zurn:sha1:6282df34fb00c3b8b686553e05f8d3172b017ed0
The FirstHopId type now records an enum that stores whether the hop
is a guard or a fallback. This change addresses concerns about
remembering to check the type or source of an Id before passing it
down to the FallbackState or GuardSet.
Making this change required an API change, so that dirmgr can
report success/failure status without actually knowing whether it's
using a fallback or a guard.
Rename Guard=>FirstHop, GuardId=>FirstHopId2022-03-30T14:40:59ZNick Mathewsonnickm@torproject.org2022-03-29T13:05:39Zurn:sha1:13af6134f6180f7241daca9206fa49ed5f26829d
This is preparation for having separate GuardId and FirstHopId types
that distinguish which back-end they index.
ListKind: Use an exhaustive match to future-proof.2022-03-30T14:40:14ZNick Mathewsonnickm@torproject.org2022-03-29T12:23:47Zurn:sha1:578f2925d96c887e1d33c4bf0014d84c8296f320Rename ExternalFailure => ExternalActivity.2022-03-30T14:40:12ZNick Mathewsonnickm@torproject.org2022-03-26T00:32:52Zurn:sha1:bdd129f23094b58b738c87d4655783004fac2274GuardMgr: some prep work for returning fallbacks as guards.2022-03-30T14:39:09ZNick Mathewsonnickm@torproject.org2022-03-25T20:49:35Zurn:sha1:a4a5f2163d7d79d152498f0a59345a22ec1d55ca
We need to extend our notion of "the origin of a guard" to include
"somewhere outside the guard list"; we need the ability to return a
FallbackDir as a Guard; and we need to remember a few more pieces of
information in each pending request.
As before, this commit may break compilation; it will be restored soon.