| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| |\
| |
| |
| |
| | |
tor-circmgr: Add more logging about timeout estimation.
See merge request tpo/core/arti!3152
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
We're seeing the logic that resets the timeouts when 18/20 connections
fail not triggering when we're expecting it to, this logging may help
figure out what's going on there.
|
| | |
| |
| |
| |
| |
| |
| | |
This is so a relay can build authenticated channels. Several keys/cert
are required for this that are within the key manager.
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is important, since some circuits require us to negotiate a new
channel, and some don't: by adding this variability, we can easily
learn a timeout based on pre-existing channels to our guards, but
then later time out if it takes a while to open a TLS connection.
This is a possible solution to part of #2079, a bug where we "learn"
a circuit timeout that is too low for us to satisfy.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The two main causes of errors were:
- Since some of the lifetime rules have changed, we no longer need
to do as many "bind a variable and immediately return it"
patterns, and so clippy now warns about them.
- We needed to adjust the explicit captures (`use<...>`)
in a couple of our RPIT instances.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Run cargo fix --edition
2. Selectively revert the "if let"->"match" changes.
These changes are meant to protect us from the lifetime changes
for "if let" bindings in Rust 2024.
But we're not actually relying on the old lifetime rules
anywhere, and the match syntax here is quite ugly.
3. Automatically revert `$pat:expr_2021` to `$pat:expr`.
(We don't actually want to restrict the expression syntax
that our macros accept).
Done with
`git grep -l expr_2021 | xargs perl -i -pe 's/expr_2021/expr/g;'`
4. Run cargo fmt.
|
| |\
| |
| |
| |
| | |
Use congestion control when "flowctl-cc" is enabled
See merge request tpo/core/arti!3118
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
This reverts commit 9dca6010d17e2a4b9deee34c9bb66e523a6ac834.
|
| | |
| |
| |
| |
| | |
We shouldn't be exposing these unless `hs-service`/`hs-client` is
enabled.
|
| | |
| |
| |
| | |
It's necessary and more verbose (and it's rather uncommon).
|
| | |
| |
| |
| |
| | |
`AbstractTunnel::extend()` was calling itself endlessly because there
was no `ClientTunnel::extend()` function to call.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Until now, we've been using `ClientCirc::path_ref()` to get the *only*
path of a circuit. Now that `ClientCirc` is a handle to a tunnel reactor
(which may or may not be multi-path), we need to decide for each call
site of `path_ref()`, if we actually want *all* paths in the tunnel, or
if we expect the tunnel to be single-path and thus want the *only* path
in the tunnel.
I've added two new APIs to address this: `all_paths()`, for getting all
the paths in the tunnel, and `single_path()` for getting the only path
in the tunnel, or an error if the tunnel is single-path.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
These were removed somewhere along the way (which is now causing the
clippy checks to fail).
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The BaseTunnel now has a start_conversation() which takes a TargetHop
meaning it can be used with a multi path tunnel.
The Conversation object has been moved into the tunnel namespace out of
the circuit one.
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the first step towards making the circmgr return high level
tunnel types (wrappers around ClientTunnel).
Future commits will then modify each subsystems to use those specific
types. They are split in order to reduce complexity.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to pull this off, the Arc requirement needs to go away because
the Arc<ClientCirc> is now within the ClientTunnel.
This commit also has a rename of the CircuitBuilder to TunnelBuilder in
order to reflect the change that it now builds a ClientTunnel.
There is a slight rename in tor-proto as well just for accuracy.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
And rename it in the process to "PendingClientTunnel".
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The CircMgr will no longer yield circuits but tunnels (src/tunnel.rs).
This is a first step to rename most circuit related objects to use
"tunnel" instead.
Some "circuit" names have been kept for more precise definitions.
No behavior changes.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
| |
Introduce the new Tunnel structs that is planned to expose publicly as a
replacement to `ClientCirc`.
Future commits will make those tunnel objects be used accross the code
base up until tor-proto which than handles Circuit directly.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
|
|
|
| |
Now instead of saying "rejected 0/40 as not usable as middle relay;
28/40 as in same family as already selected", we say "rejected 28/40
as in same family as already selected".
Closes #2006.
|
| |
|
|
|
|
| |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| |
|
|
|
| |
The fallback CC algorithm is _always_ fixed-window, and we should only
use it when the selected CC algorithm is not supported.
|
| |
|
|
|
|
|
|
|
| |
Now tor-circmgr no longer needs to check which Protover capabilities
are enabled, or construct a separate CircParameters for each hop.
Instead, tor-proto decides whether to use the fallback CC mode,
based on whether the target supports FLOWCTRL_CC.
Closes #1967.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
(text from Gabi)
|
| | |
|
| |
|
|
| |
On !3007, @gabi-250 says that it was a mistake to have it be Naive.
|
| |
|
| |
Co-authored-by: gabi-250 <[email protected]>
|
| |
|
|
| |
Closes #1911.
|
