summaryrefslogtreecommitdiff
path: root/crates/tor-guardmgr
Commit message (Collapse)AuthorAgeFilesLines
* Bump all arti*, tor* crates to 0.2.0Nick Mathewson2022-04-011-16/+16
| | | | | | | | 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 derive_more to derive AsRef.Nick Mathewson2022-03-302-12/+4
|
* Reformat tor-guardmgr/Cargo.toml.Nick Mathewson2022-03-301-18/+18
|
* Fix some Rustdoc links.Nick Mathewson2022-03-304-5/+5
|
* Refactor FirstHopId into type-differentiated formNick Mathewson2022-03-307-169/+322
| | | | | | | | | | | 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=>FirstHopIdNick Mathewson2022-03-306-70/+84
| | | | | This is preparation for having separate GuardId and FirstHopId types that distinguish which back-end they index.
* FallbackState: Use itertools::merge_join_by.Nick Mathewson2022-03-301-100/+8
| | | | | This replaces a hand-coded replacement that was probably a little less efficient.
* Fold fallback::Status::reset() into its (only) caller.Nick Mathewson2022-03-301-7/+2
|
* Rename FallbackState::lookup_mut => get_mut.Nick Mathewson2022-03-301-12/+12
|
* Rename FallbackSet => FallbackState.Nick Mathewson2022-03-303-15/+15
|
* Refactor select_guard_with_expand to use match and log errors.Nick Mathewson2022-03-301-10/+13
|
* ListKind: Use an exhaustive match to future-proof.Nick Mathewson2022-03-301-1/+4
|
* Clarify documentation about GuardUsable constructorsNick Mathewson2022-03-301-4/+10
|
* Add a TODO about an unslightly type.Nick Mathewson2022-03-301-0/+2
|
* Clean up a rustdoc linkIan Jackson2022-03-301-1/+1
|
* guardmgr::fallback::set: basic unit tests.Nick Mathewson2022-03-301-10/+190
|
* Rename ExternalFailure => ExternalActivity.Nick Mathewson2022-03-302-11/+10
|
* Replace the fallback directories when they change in the config.Nick Mathewson2022-03-302-0/+122
| | | | | | 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.
* Add status tracking to FallbackDir.Nick Mathewson2022-03-305-24/+260
| | | | | | | | | | | We do this by creating a new FallbackSet type that includes status information, and updating the GuardMgr APIs to record success and failure about it when appropriate. We can use this to mark FallbackDirs retriable (or not). With this change, FallbackDir is now stored internally as a Guard in the GuardMgr crate. That's fine: the FallbackDir type really only matters for configuration.
* GuardMgr: Return fallback directories when appropriate.Nick Mathewson2022-03-301-26/+67
| | | | | | | | | | | We only do this when we fail to get a regular guard (e.g., because they're all down), and when we have been asked for a guard for a one-hop directory. Most of the change in this commit is plumbing to make all of the types match up. As before, compilation may still be broken.
* Fix typos in guardmgr/lib.rsNick Mathewson2022-03-301-2/+2
|
* GuardMgr: some prep work for returning fallbacks as guards.Nick Mathewson2022-03-303-4/+40
| | | | | | | | | 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.
* Turn FallbackList into a real type, and store one in GuardMgr.Nick Mathewson2022-03-304-5/+85
| | | | | | | | | | | | | | 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.
* guardmgr: move error types into new err.rs module.Nick Mathewson2022-03-303-73/+79
| | | | This is more in keeping with the rest of our code.
* Move fallback.rs into guardmgr.Nick Mathewson2022-03-302-0/+87
| | | | | | | 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.
* Remove allow(clippy::disallowed_methods) lint.Nick Mathewson2022-03-303-18/+0
|
* Merge branch 'no-system-time' into 'main'eta2022-03-303-6/+28
|\ | | | | | | | | | | | | Don't use SystemTime::now() Closes #306 See merge request tpo/core/arti!365
| * use wallclock where possible in teststrinity-1686a2022-02-263-6/+28
| |
* | GuardMgr:: generalize GuardId::from_relay.Nick Mathewson2022-03-213-6/+10
| |
* | GuardMgr: new API to record guard problems from outside the crate.Nick Mathewson2022-03-212-11/+44
| | | | | | | | | | We'll need this so that we can say "This guard behaved bogusly as a directory cache; try somebody else."
* | GuardMgr: revise handling of "all guards are down".Nick Mathewson2022-03-213-21/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When all guards are down, we would previously mark them all as up, and retry aggressively. But that's far too aggressive: if there's something wrong with our ability to connect to guards, it makes us hammer the network over and over, ignoring all the guard retry timeouts in practice. Instead, * We now allow the `pick_guard()` function to fail without automatically retrying. * We give different errors in the cases when all our guards are down, and when all of the guards selected by our active usage are down. * Our "guards are down" error includes the time at which a guard will next be retriable. This is part of #407.
* | GuardMgr: use decorrelated-jitter backoff for retrying guards.Nick Mathewson2022-03-211-80/+34
| | | | | | | | | | | | | | | | | | | | | | | | C tor used one schedule, and guard-spec specified another. But in reality we should probably use a randomized schedule to retry guards, for the reasons explained in the documentation for RetrySchedule. I've chosen the minima to be not too far from our previous minima for primary and non-primary guards. This is part of #407.
* | derive_builder: Switch to upstream 0.11Ian Jackson2022-03-161-1/+1
| | | | | | | | | | | | | | | | | | 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
* | humantime: Update to humantime-serde 1.1.1Ian Jackson2022-03-141-1/+1
| | | | | | | | | | | | | | | | This has the humantime_serde::option module, which we have upstreamed and are about to switch to. The remaining dependency with version = "1" is going to be removed in a moment.
* | Use git source for derive_builder for now, for attrs featureIan Jackson2022-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We are going to want to specify custom attributes on fields of the builder struct. This feature was missing from derive_builder. This commitid is the current head of my MR branch https://github.com/colin-kiegel/rust-derive-builder/pull/237 https://github.com/ijackson/rust-derive-builder/tree/builder-field-attrs Using the commitid prevents surprises if that branch is updated. We will require this newer version of derive_builder. The version will need to be bumped again later, assuming the upstream MR is merged and upstream do a release containing the needed changes.
* | Move skip_fmt into tor-basic-utilsIan Jackson2022-03-042-2/+2
| | | | | | | | | | | | | | Code motion and the minimal mechanical changes. As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/375#note_2783078
* | Replace manual Default impls with educe in tor-guardmgrIan Jackson2022-03-023-21/+13
| |
* | Replace manual Debug impl with educe in tor-guardmgrIan Jackson2022-03-022-11/+9
| |
* | Merge branch 'clippy-allow-arc-clone' into 'main'Nick Mathewson2022-03-011-1/+0
|\ \ | | | | | | | | | | | | Disable clippy::clone_on_ref_ptr See merge request tpo/core/arti!352
| * | Disable clippy::clone_on_ref_ptrIan Jackson2022-02-241-1/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This lint is IMO inherently ill-conceived. I have looked for the reasons why this might be thought to be a good idea and there were basically two (and they are sort of contradictory): I. "Calling ‘.clone()` on an Rc, Arc, or Weak can obscure the fact that only the pointer is being cloned, not the underlying data." This is the wording from https://rust-lang.github.io/rust-clippy/v0.0.212/#clone_on_ref_ptr It is a bit terse; we are left to infer why it is a bad idea to obscure this fact. It seems to me that if it is bad to obscure some fact, that must be because the fact is a hazard. But why would it be a hazard to not copy the underlying data ? In other languages, faliing to copy the underlying data is a serious correctness hazard. There is a whose class of bugs where things were not copied, and then mutated and/or reused in multiple places in ways that were not what the programmer intended. In my experience, this is a very common bug when writing Python and Javascript. I'm told it's common in golang too. But in Rust this bug is much much harder to write. The data inside an Arc is immutable. To have this bug you'd have use interior mutability - ie mess around with Mutex or RefCell. That provides a good barrier to these kind of accidents. II. "The reason for writing Rc::clone and Arc::clone [is] to make it clear that only the pointer is being cloned, as opposed to the underlying data. The former is always fast, while the latter can be very expensive depending on what is being cloned." This is the reasoning found here https://github.com/rust-lang/rust-clippy/issues/2048 This is saying that *not* using Arc::clone is hazardous. Specifically, that a deep clone is a performance hazard. But for this argument, the lint is precisely backwards. It's linting the "good" case and asking for it to be written in a more explicit way; while the supposedly bad case can be written conveniently. Also, many objects (in our codebase, and in all the libraries we use) that are Clone are in fact simply handles. They contain Arc(s) (or similar) and are cheap to clone. Indeed, that is the usual case. It does not make sense to distinguish in the syntax we use to clone such a handle, whether the handle is a transparent Arc, or an opaque struct containing one or more other handles. Forcing Arc::clone to be written as such makes for code churn when a type is changed from Arc<Something> to Something: Clone, or vice versa.
* | Bump all crates to 0.1.0arti-v0.1.0Nick Mathewson2022-03-011-15/+15
| |
* | Merge branch 'always-coarsetime' into 'main'eta2022-02-281-1/+1
|\ \ | | | | | | | | | | | | Make coarsetime dependency and traffic-timestamping non-optional. See merge request tpo/core/arti!358
| * | Make coarsetime dependency and traffic-timestamping non-optional.Nick Mathewson2022-02-251-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | Previously coarsetime and the traffic-timestamp feature were enabled, since they were only required for a small corner of the guardmgr algorithm. But in 1.0 and beyond we'll be adding a bunch of other features (eg, netflow padding, DoS prevention) that will need coarsetime all over the place. And since we're going to be doing coarsetime all over the place, the previous justification for making traffic-timestamping optional (the tiny performance hit) is no longer relevant.
* / impl Debug for various internal typesIan Jackson2022-02-251-0/+11
|/ | | | | | | | I wanted this while debugging something. The ad-hoc impl Debug with f.debug_struct is getting repetitive and I've already perpetrated one copy-paste mistake. We should consider using something like the `educe` crate's Clone.
* Remove clippy::needless_borrow exception in CI.Nick Mathewson2022-02-201-1/+0
| | | | | This exception is no longer necessary now that the underlying CI bug is fixed.
* Change deny(clippy::all) to warn(clippy::all).Nick Mathewson2022-02-141-1/+1
| | | | Closes #338.
* Add TODOs on uncertain points about time_since_last_trafficNick Mathewson2022-02-091-0/+1
| | | | | | This edge-case was there even before the migration of 595fe1ab881b94106649, but now it's more explicit and ought to be revisited.
* Remove the use of Mutex in channel unused_since timestampYuan Lyu2022-02-081-5/+10
|
* Make SpawnError wrappers contain a 'spawning' stringNick Mathewson2022-02-041-11/+25
| | | | | (By our convention, these errors should say what we were trying to spawn when the error occurred.)
* errors: impl HasKind for GuardMgrErrorIan Jackson2022-02-041-0/+12
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 19:58:55 +0000