mirrors/arti.git/crates/tor-circmgr/src/config.rs, branch arti-v0.2.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.2.02022-03-30T18:22:28ZUse a lower default for max_retries.2022-03-30T18:22:28ZNick Mathewsonnickm@torproject.org2022-03-30T18:22:28Zurn:sha1:432bb5ce627a5add1ed2c68130cfaa2d60672900
The older default seems (experimentally) to be ridiculously high.
Generally, if we can't build a circuit within a handful attempts,
that circuit has already timed out... unless there is a fast-failure
condition, in which case we're just hammering the network (or our
view of it.)
Found with `arti-testing` for #329.
Turn FallbackList into a real type, and store one in GuardMgr.2022-03-30T14:39:06ZNick Mathewsonnickm@torproject.org2022-03-25T20:44:12Zurn:sha1:9da43189f36b19681d10b78ef982c52c929b4573
The guard manager is responsible for handing out the first hops of
tor circuits, keeping track of their successes and failures, and
remembering their states. Given that, it makes sense to store this
information here. It is not yet used; I'll be fixing that in
upcoming commits.
Arguably, this information no longer belongs in the directory
manager: I've added a todo about moving it.
This commit will break compilation on its own in a couple of places;
subsequent commits will fix it up.
Merge branch 'config-partials-transparent' into 'main'2022-03-17T12:30:46ZIan Jacksoniwj@torproject.org2022-03-17T12:30:46Zurn:sha1:40bede587c8d9a0a29ad103832a9c9cd4a2f5982
Absolish builders for CircMgrConfig and DirMgrConfig
See merge request tpo/core/arti!417Add rationale for CircMgrConfig transparency and trait2022-03-16T19:31:08ZIan Jacksonijackson@chiark.greenend.org.uk2022-03-16T19:30:21Zurn:sha1:ab352881e3d010b575c6c6495e37b4ee90facae4Provide define_accessor_trait and use it to generate CircMgrConfig2022-03-16T19:31:05ZIan Jacksonijackson@chiark.greenend.org.uk2022-03-16T19:30:10Zurn:sha1:82aa4b902a77ce703cbb94a36c6265143741285bMake CircMgrConfig transparent (and make it a trait)2022-03-16T19:30:59ZIan Jacksonijackson@chiark.greenend.org.uk2022-03-16T17:55:40Zurn:sha1:8bde40fdd379118b21a98f5aaa9e856027596b74
See commentary for the rationale.
derive_builder: Switch to upstream 0.112022-03-16T16:34:44ZIan Jacksonijackson@chiark.greenend.org.uk2022-03-16T14:52:12Zurn:sha1:da787d074a04c97a1e28709f53f1cff5127b7ac9
This has the different syntax for builder field attributes than what I
originally proposed in my MR, and which therefore is in the pinned
branch.
My upstream MR for the field attributes feature was morged:
https://github.com/colin-kiegel/rust-derive-builder/issues/239
Use new upstream humantime_serde_option feature2022-03-14T10:33:59ZIan Jacksonijackson@chiark.greenend.org.uk2022-03-11T17:21:15Zurn:sha1:409c5dd6d2fbb68353287381d3305dbd6917d521
Replace all uses of our copy of this code.
Drop remaining conversion from FooConfig to FooConfigBuilder2022-03-07T15:58:53ZIan Jacksonijackson@chiark.greenend.org.uk2022-03-04T11:59:49Zurn:sha1:1b1ce8cc82f680d6ef1d7b3775e042e4156456a6Derive Deserialize for derive-builder-generated config builders2022-03-07T15:58:53ZIan Jacksonijackson@chiark.greenend.org.uk2022-03-04T14:22:17Zurn:sha1:5203311a977f18f9b908907f9fd3b24cded84b51
I used
git-grep -P '\#\[serde\((?!default|deny_unknown)'
to find places where I needed to add additional attributes on the
builder method fields.
This is currently a bit duplicative, but when #371 is completely done,
the validated (non-builder) configs won't need to be Deserialize any
more.
This is part of #371 and #372.