mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.4.0 2022-05-23T16:55:37Z 2022-05-23T16:55:37Z Nick Mathewson nickm@torproject.org 2022-05-23T16:32:31Z urn:sha1:546ae3000eb179aedc97de30b0ccdb1d45b93395 It's a little overzealous sometimes, but it's mostly to the good. 2022-04-25T17:06:26Z Nick Mathewson nickm@torproject.org 2022-04-25T16:40:33Z urn:sha1:2f6bc6bdc431fa36de70a167eea777dcf3f60bf2 Remove all `use` statements for `TryFrom` and `TryInto`. These are now redundant in Rust 2021. 2022-04-12T12:41:32Z Nick Mathewson nickm@torproject.org 2022-04-12T12:41:32Z urn:sha1:3d5276a9cc6030751f9b4ff541c4055a4e66f75c This feature is similar to ChanProvenance from ChanMgr, except that we don't yet need to report it outside the crate. I'm going to use it to distinguish newly created circuits from existing circuits in the preemptive circuit builder. 2022-04-04T15:41:00Z Nick Mathewson nickm@torproject.org 2022-04-04T15:41:00Z urn:sha1:36440a957c762f2dfe43569a0545cbbda7f738a9 This lets us say that the UsageMismatch cases in some parts of the code reflect a programming error (RetryTime::Never), whereas in other case it reflects another circuit request getting to the circuit first (RetryTime::Immediate). 2022-04-04T15:15:18Z Nick Mathewson nickm@torproject.org 2022-03-31T19:41:38Z urn:sha1:6d8a6b42e7cc9737c3a93ff6a23aaaea11e45fbe Use the new RetryTime type and its associates to decide how long to wait (if at all) between attempts to build a circuit. Closes #421. Part of #329. 2022-04-04T15:15:18Z Nick Mathewson nickm@torproject.org 2022-03-31T19:17:02Z urn:sha1:f7810d42eb953bf57d9d777fc823087211350452 Previously we did not distinguish errors that came from pending circuits from errors that came from the circuits we were building. We also reported errors as coming from "Left" or "Right", instead of a more reasonable description. 2022-04-04T15:14:52Z Nick Mathewson nickm@torproject.org 2022-03-31T18:51:02Z urn:sha1:86c59dd1f337919023779ad92bb08ca79e876158 We were treating restrict_mut() failures as internal errors, and using internal errors to represent them. But in fact, these failures are entirely possible based on timing. Here's how it happens: * Two different circuit requests arrive at the same time, and both notice a pending circuit that they could use. * The pending circuit completes; both pending requests are notified. * The first request calls restrict_mut(), and restricts the request in such a way that the second couldn't use it. * The second request calls restrict_mut(), and gets a failure. Because of this issue, we treat these errors as transient failures and just wait for another circuit. Closes #427. (This is not a breaking API change, since `AbstractSpec` is a crate-private trait.) 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. 2022-03-30T14:39:06Z Nick Mathewson nickm@torproject.org 2022-03-25T20:44:12Z urn: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. 2022-03-30T14:34:48Z Nick Mathewson nickm@torproject.org 2022-03-25T17:38:01Z urn:sha1:80b65c3a4d4108c6b4b0cb91722f89c8e5859b7d This is the logical place for it, I think: the GuardMgr's job is to pick the first hop for a circuit depending on remembered status for possible first hops. Making this change will let us streamline the code that interacts with these objects.