mirrors/arti.git/crates/tor-circmgr, branch arti-v0.2.0 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.2.0 2022-04-01T13:15:18Z Bump all arti*, tor* crates to 0.2.0 2022-04-01T13:15:18Z Nick Mathewson nickm@torproject.org 2022-04-01T13:15:18Z urn:sha1:5b2fc118df0524144e6b2c34fdcce3d0fb692d24 Not all of these strictly need to be bumped to 0.2.0; many could go to 0.1.1 instead. But since everything at the tor-rtcompat and higher layers has had breaking API changes, it seems not so useful to distinguish. (It seems unlikely that anybody at this stage is depending on e.g. tor-protover but not arti-client.) Use a lower default for max_retries. 2022-03-30T18:22:28Z Nick Mathewson nickm@torproject.org 2022-03-30T18:22:28Z urn: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. circmgr: limit circuit attempts when launch_parallelism > 1. 2022-03-30T18:14:52Z Nick Mathewson nickm@torproject.org 2022-03-30T18:14:52Z urn:sha1:bd798764a47332393fd6b036093dba9c73770d79 Previously, if we had launch_parallelism > 1, and we were willing to retry building a circuit max_retries times, then we'd launch up to max_retries * launch_parallelism circuits before giving up. Ouch! With this patch, we try to keep the total number of circuits planned and attempted to the actual max_retries limit. Part of #329; found with arti-testing. Run cargo fmt one more time for good measure. 2022-03-30T14:41:57Z Nick Mathewson nickm@torproject.org 2022-03-30T14:41:57Z urn:sha1:2bb3ba7886571153a46dc6d5de4a6e6876863957 Reformat several Cargo.toml files with 100-char-wide lines. 2022-03-30T14:41:40Z Nick Mathewson nickm@torproject.org 2022-03-29T17:39:03Z urn:sha1:1feb7eecacf0718f46a36175b75ffdcc152b340c Refactor FirstHopId into type-differentiated form 2022-03-30T14:41:39Z Nick Mathewson nickm@torproject.org 2022-03-29T14:55:20Z urn: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=>FirstHopId 2022-03-30T14:40:59Z Nick Mathewson nickm@torproject.org 2022-03-29T13:05:39Z urn:sha1:13af6134f6180f7241daca9206fa49ed5f26829d This is preparation for having separate GuardId and FirstHopId types that distinguish which back-end they index. DirPathBuilder::pick_path: re-order match cases for clarity. 2022-03-30T14:40:14Z Nick Mathewson nickm@torproject.org 2022-03-29T12:39:04Z urn:sha1:951b800988ee00048be36a9abf5bcf60eeb19f96 Rename ExternalFailure => ExternalActivity. 2022-03-30T14:40:12Z Nick Mathewson nickm@torproject.org 2022-03-26T00:32:52Z urn:sha1:bdd129f23094b58b738c87d4655783004fac2274 Replace the fallback directories when they change in the config. 2022-03-30T14:39:09Z Nick Mathewson nickm@torproject.org 2022-03-26T00:28:05Z urn:sha1:d88e9d676e8204078152fccc7f9ef893e136ac03 The code here uses a new iterator type, since I couldn't find one of these on crates.io. I tried writing the code without it, but it was harder to follow and test.