summaryrefslogtreecommitdiff
path: root/crates/tor-circmgr/src
Commit message (Collapse)AuthorAgeFilesLines
* *: suppress cognitive_complexity warnings from nightlyNick Mathewson2025-05-293-0/+5
| | | | | | | | | | | | | Apparently clippy nightly is better (or worse?) about detecting complex functions than before, so I'm suppressing these warnings where they occur. I have mixed feelings about these warnings: On the plus side, they really do help to detect functions that are twistier than they need to be. On the minus side, they get confused by tracing macros, and the "allows" do pile up. But on the plus side, those "allows" do provide a way to find functions that need to be refactored, and they are never uglier than the functions they decorate.
* hspool: Explain _why_ ClientRend is Guarded.Nick Mathewson2025-05-221-4/+12
| | | | (text from Gabi)
* hspool: refactor path match to be exhaustive.Nick Mathewson2025-05-221-7/+11
|
* hspool: ClientRend first should be GuardedNick Mathewson2025-05-221-4/+5
| | | | On !3007, @gabi-250 says that it was a mistake to have it be Naive.
* Apply 1 suggestion(s) to 1 file(s)Nick Mathewson2025-05-221-1/+1
| | | Co-authored-by: gabi-250 <[email protected]>
* circmgr: Apply last-hop-in-stem usage when retrieving a stem circ.Nick Mathewson2025-05-201-20/+85
| | | | Closes #1911.
* circmgr: when building client rend stems, make sure last hop has new_rend usage.Nick Mathewson2025-05-202-28/+72
|
* guardmgr, circmgr: Make vanguard selection take a RelaySelector.Nick Mathewson2025-05-203-32/+62
| | | | | | This is the preferred type for choosing a relay, since unlike a RelayExclusion, it lets us add multiple restrictions, and a relay usage.
* circmgr: Propagate Option<HsCircKind> down to path selection functionsNick Mathewson2025-05-204-46/+103
| | | | | | We'll need this in order to build paths that are specifically for client rend circuits. I thought of using a boolean here, but that had potential to get ugly in the future.
* circmgr: Change get_or_launch_stem to take a HsCircKindNick Mathewson2025-05-201-13/+22
| | | | | | We're going to be looking at this a little more closely in order to decide whether the last hop of a stem can be used as a rendezvous point.
* circmgr: rename ensure_circuit_{compatible_with => can_extend_to}_targetNick Mathewson2025-05-201-6/+3
| | | | | There are two other functions called "compatible_with_target" that check a different property, so this one was confusing.
* relay-selection: tweak messages about rejection reasonsNick Mathewson2025-05-201-3/+3
| | | | | | "Useless as xyz" implies that the relay wouldn't work at all as a middle relay, but that's not true: it _would_ work somewhat, but be can't use it for some other reason.
* tor-proto: Future-proof some comments about path_ref() errors.Gabriela Moldovan2025-05-151-2/+2
| | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2996#note_3199590
* tor-proto: Return Error::Protocol if ClientCirc accessors return an error.Gabriela Moldovan2025-05-151-32/+40
| | | | | | | | | | The `ClientCirc` accessors will only return an error if the underlying circuit is closed, so it doesn't make sense to map these errors to `Bug`. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2996#note_3199072 and https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2996#note_3199073
* tor-proto: Update the TunnelMutableState when a circuit is removed.Gabriela Moldovan2025-05-154-13/+35
| | | | | | | | This is messy, because `ClientCirc::{path_ref, n_hops, ..}` become fallible (we can't unwrap the result, because when a circuit is closed, its state gets removed from the `TunnelSharedState`, but its `ClientCirc` handle continues to exist, so any attempt to retrieve the state will result in an `Err`).
* Resolve clippy warnings from 1.83Nick Mathewson2025-05-131-2/+1
| | | | | Now that our MSRV is 1.83, clippy is happy to make more recommendations for us.
* Merge branch 'clientcirc_extend' into 'main'Nick Mathewson2025-05-065-19/+11
|\ | | | | | | | | | | | | tor-proto: New extend() and create_firsthop() to pick between ntor and ntor3 Closes #1970 See merge request tpo/core/arti!2967
| * proto: Provide and use a create_firsthop() wrapper too.Nick Mathewson2025-04-281-7/+2
| |
| * circmgr: Rename AbstractCirc::{extend_ntor => extend}Nick Mathewson2025-04-284-6/+5
| | | | | | | | | | We don't want to be thinking about ntor vs ntor3 in circmgr.
| * tor-proto: New extend() to pick between ntor and ntor3Nick Mathewson2025-04-282-7/+5
| | | | | | | | | | | | | | | | | | In the future, when we add more circuit handshakes (PQ anyone?) we'll want to have the logic for choosing which to use be unified. Almost nobody calling tor-proto should need to care which circuit handshake is going to be used. Closes #1970.
* | circmgr: Make path module public on "--features=experimental-api"Nick Mathewson2025-05-051-1/+9
|/ | | | | | | | | | | | Back in 4c1eb94173521bc5104449327650e20ffe32afa7, for sensible reasons, we made `tor_circmgr::path` a crate-private module. But when we did that, we lost the ability for callers to construct circuits with custom paths. This will make it possible for callers to build custom circuits again, without committing to a very-long-term API for that. Closes #1981.
* tor-circmgr: put vegas cc in `CircParameters` behind `if false`Steven Engler2025-04-231-22/+42
| | | | | This means that even with the "flowctl-cc" feature enabled, we shouldn't try to negotiate congestion control.
* tor-circmgr: only use congestion control if "flowctl-cc" feature is enabledSteven Engler2025-04-231-2/+5
|
* tor-circmgr: switch from `supports_{known,named}_subver()`Steven Engler2025-04-231-3/+3
|
* circ: Don't pin CC algorithm to FixedWindow anymoreDavid Goulet2025-04-231-4/+1
| | | | | | | | | | | Circuit handshake negotiation for congestion control has been added in previous commit so stop pinning the algorithm. This commit marks the start of congestion control usage by arti client. Closes #1817 Signed-off-by: David Goulet <[email protected]>
* circ: Apply possible subprotocol changes to circ paramsDavid Goulet2025-04-231-5/+20
| | | | | | | | | | | | | Congestion control can change the circuit parameters if the relay we are negotiating with doesn't support FlowCtrl=2. This commit adds a function in the circuit builder that will apply any changes to the circuit parameters of the hop based on the hop protocol values. For now, only congestion control applies. Part of #1817 Signed-off-by: David Goulet <[email protected]>
* circ: Remove CircParameters reference in call stackDavid Goulet2025-04-235-17/+16
| | | | | | | | | | | This avoids cloning the object and instead allows us to have a CircParameters per hop on the circuit path. This will come handy with congestion control where each hop might have different congestion control parameters. Part of #1817 Signed-off-by: David Goulet <[email protected]>
* congestion: Setup a fallback algorithm in the paramsDavid Goulet2025-04-231-0/+1
| | | | | | | | | | | | | | | | CircParameters is built before path selection and thus once we start building the hops, we can't access the consensus values that were used to build it in the first place. For congestion control, we require a fallback algorithm in case the hop doesn't support FlowCtrl=2. This commit adds a "fallback_alg" to the CC parameters which will be used for this exact case. Part of #1817 Signed-off-by: David Goulet <[email protected]>
* tor-circmgr: Added TODO about replacing OnceCellhashcatHitman2025-04-171-0/+8
| | | | | - [`once_cell::sync::OnceCell`] should be replaced by [`std::sync::OnceLock`] once the blocking methods are stabilized and within our MSRV.
* tor-circmgr: clean up after "ntor_v3" feature flag removalSteven Engler2025-04-011-21/+13
|
* tor-circmgr: removed "ntor_v3" feature flagSteven Engler2025-04-011-11/+0
| | | | ntor v3 is now always enabled.
* Remove semver.md files post-release.Gabriela Moldovan2025-04-011-2/+0
|
* tor-circmgr: Explicit type annotationClara Engler2025-03-261-1/+1
| | | | | | | This commit adds an explicit type annotation to the learning_timeouts() function, as leaving it out yielded an error while trying to compile tor-circmgr in a project that had this crate deep down in its supply chain.
* circmgr: test behavior of IteratorRandom::choose_multipleNick Mathewson2025-03-251-1/+15
|
* Merge branch 'named_protovers' into 'main'David Goulet2025-03-201-7/+7
|\ | | | | | | | | | | | | protover: Add support for subprotocol version mnemonics. Closes #1891 See merge request tpo/core/arti!2854
| * Use named subprotocol versions throughout arti.Nick Mathewson2025-03-121-7/+7
| |
* | Merge branch 'timeout_est_overflow' into 'main'Nick Mathewson2025-03-191-3/+11
|\ \ | | | | | | | | | | | | | | | | | | Impose a maximum on our fallback estimated timeout Closes #1693 See merge request tpo/core/arti!2842
| * | Impose a maximum on our fallback estimated timeoutNick Mathewson2025-03-061-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fallback timeout is the one that we use when we have insufficient data. We reset our observations, and maybe rebuild our circuits, when we find that too many circuits have failed recently. When we do so, we double our fallback timeout. Previously we had no limit, which could lead to overflow (#1693). In this commit we impose a maximum of 2 hours, which is ridiculously high. (C tor uses a maximum of INT32_MAX seconds, which is even more ridiculously high.) Closes #1693.
* | | squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-181-1/+1
| | | | | | | | | | | | - Several methods have been moved out of SliceRandom.
* | | squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-185-8/+8
| |/ |/| | | | | - `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
* | tor-rtmock: allow-Decorate every use of MockSleepProviderIan Jackson2025-03-062-1/+19
|/ | | | | | | MockSleepProvider and MockSleepRuntime have been declared deprecated by the docs for some time. We're about to mark them `#[deprecated]`. This commit has been split out for clarity of review.
* relay-selection: Add FamilyRules to exclude_relays_in_same_family.Nick Mathewson2025-02-252-12/+22
| | | | | | | | | | | | When we're trying to exclude relays by family, we need to know which lists to look at. This information ultimately comes from the network parameters. We could avoid this change if we just told clients "look at all family information all the time", but that's not what the proposal says. This is a breaking change.
* congestion: Don't use Vegas just yetDavid Goulet2025-01-161-1/+4
| | | | | | | | | | Without circuit negotiation and flow control (XON/XOFF), the Vegas algorithm can not be used. Temporarily, this commit pins the algorithm to fixed window until we have the above. Signed-off-by: David Goulet <[email protected]>
* Make cargo clippy happyDavid Goulet2025-01-161-4/+4
| | | | Signed-off-by: David Goulet <[email protected]>
* Add missing semver.md filesDavid Goulet2025-01-161-0/+2
| | | | | | Both in tor-proto and tor-circmgr. Signed-off-by: David Goulet <[email protected]>
* circmgr: Remove the CircParameters build .expect()David Goulet2025-01-164-53/+26
| | | | | | Instead, return an error and make all call site handle it. Signed-off-by: David Goulet <[email protected]>
* circ: Specialize the circparams from netparams functionDavid Goulet2025-01-164-64/+102
| | | | | | | | | | | | | | | Congestion control parameters have specific values depending on the circuit type. Instead of using a CircuitType, which is removed in this commit, specialize the function in this case onion and exit. This allows us to get rid of CircuitType and solely use TargetCircUsage instead. At this commit, we use .expect() on the Builder. Future commit will remove this to return a Result in case of failure. Worth noting that we don't expect one. Signed-off-by: David Goulet <[email protected]>
* congestion: Remove Default from every parametersDavid Goulet2025-01-161-0/+2
| | | | | | | Important to enforce that every field is explicitely set so we avoid forgetting fields. Signed-off-by: David Goulet <[email protected]>
* congestion: Make the cc_alg values a caret_int for better code semanticDavid Goulet2025-01-161-4/+4
| | | | Signed-off-by: David Goulet <[email protected]>
* circmgr: Modify CircParameters for congestion controlDavid Goulet2025-01-164-27/+128
| | | | | | | | | | | | | | The congestion control parameters are created from the consensus parameters (netparams) and then put into the CircParameters object that is then passed down the tor-proto crate. Because different parameters are selected depending on the circuit type (onion vs exit vs sbws), a CircuitType enum is introduced for the sole purpose of being used to select the right parameters. Related #534 Signed-off-by: David Goulet <[email protected]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 01:17:24 +0000