mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.2.0 2022-03-30T18:14:52Z 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. 2022-03-24T18:43:54Z trinity-1686a trinity@deuxfleurs.fr 2022-03-24T18:43:54Z urn:sha1:8dc6e958aa305236054a43c0db74dda9176e0702 2022-03-24T17:56:22Z trinity-1686a trinity@deuxfleurs.fr 2022-03-24T17:56:22Z urn:sha1:de5f517da64755feaab61485bc15e2eab2860950 2022-03-21T19:06:05Z Nick Mathewson nickm@torproject.org 2022-03-21T19:06:05Z urn:sha1:4a644a98791dace07434da3c970b31b74b35c90d 2022-03-21T13:06:32Z Nick Mathewson nickm@torproject.org 2022-03-17T13:33:47Z urn:sha1:d778a922255a75e36baa5296451e9982045ac777 It'll soon more convenient to pass in FallbackDirs as a slice of references, rather than just a slice of FallbackDirs: I'm going to be changing how we handle these in tor-dirmgr. 2022-03-21T13:06:32Z Nick Mathewson nickm@torproject.org 2022-03-16T18:15:29Z urn:sha1:451a53a5bfc8f8992d603f638956d144512cd70c If all guards are down and they won't be retriable for a while, try waiting that long to get whichever guard _is_ retriable. Additionally, if we are making multiple circuit plans in parallel, only report our planning as having failed if we failed at making _all_ the plans. Previously we treated any failure as fatal for the other plans, which could lead to trouble in the case when guards were all down or pending. Part of #407. 2022-03-16T18:24:23Z trinity-1686a trinity@deuxfleurs.fr 2022-03-15T23:30:41Z urn:sha1:4eb90b72c04b34fb54baa197b1bf85734a769f64 2022-03-02T17:04:07Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-03-02T15:24:18Z urn:sha1:90f86b47e468e6f5cdf5375787fac7630406f8a5 When I wrote this, I arranged to skip dumping the field `pending`. This must have been because I thought that either (a) PendingEntry couldn't `#[derive(Debug)]` (but it can) and/or (b) Some of the fields of PendingEntry ought not to be dumped because they might contain (eg) packet data. But I think they don't: there's just the spec, and the Result which is (basically) a Circ. I tried preseving something closer to the original using educe, but educe gets somehow tangled up with the generics, and the result fails to compile. I haven't investigated this further.