| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
A "tunnel" is a higher level concept we'll want to avoid using from now
on when talking about the proto implementation.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|
| | |
| |
| |
| |
| |
| |
| | |
This reorganizes the `relay_tunnel` module as per @dgoulet's
[suggestion].
[suggestion]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3162/diffs#note_3240092
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a placeholder, and will likely change quite a bit in the near
future. In particular, much of this is copied from the client tunnel
reactor (a future change will refactor both of them to reduce/minimize
code duplication).
I'm adding this placeholder because the channel code will soon
need the ability to create and launch circuit reactors.
|
| | |
| |
| |
| | |
We will soon need this in the relay reactor.
|
| | |
| |
| |
| | |
Part of #1447
|
| | |
| |
| |
| |
| |
| |
| | |
The new relay tunnel reactor will live in this module for now. This is
temporary, as I expect we will soon need to reorganize this crate a
little bit, to more clearly separate the client-specific parts from the
relay ones.
|
| |\ \
| |/
|/|
| |
| | |
Fix clippy errors on nightly
See merge request tpo/core/arti!3148
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
```text
warning: duplicated attribute
--> crates/tor-hsservice/src/timeout_track.rs:630:14
|
630 | #![allow(clippy::needless_pass_by_value)] // TODO hoist into standard lint block
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
|
| |/
|
|
|
|
|
|
|
| |
This replaces a `send_unbounded()` call with `send_msg()`. Now
`send_msg()` is the only place where we call `send_unbounded()` in the
tunnel reactor, which makes it a bit easier to see which callsites have
the potential to cause buffering in the channel sink.
Prompted by #2112
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Enable counter-galois onion negotiation and make it work.
See merge request tpo/core/arti!3133
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This change fixes a CGO bug: when extending circuits with ntorv3,
we were never actually using CGO encryption for the newly
constructed layer.
This change also simplifies the code a bit, by un-parameterizing
CircuitExtender a bit.
|
| | | |
|
| | |
| |
| |
| | |
Now that we can negotiate CC, we can negotiate CGO.
|
| | |
| |
| |
| |
| | |
We're not sure why `cargo fix` did this, but it doesn't seem
necessary.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
|
| |
Since we now allow it to be turned on, we can include it among our
supported protocols.
|
| | |
|
| |\
| |
| |
| |
| | |
Use congestion control when "flowctl-cc" is enabled
See merge request tpo/core/arti!3118
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| | |
When the `send-control-msg` feature is enabled, we reexport it from
`tor-proto`, so it needs to be made `pub`.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Previously the error message would say `Single circuit getter on multi
path tunnel`. The new error message makes it clearer that calling
`ClientTunnel::allow_stream_requests()` on a multi path tunnel is not
supported.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the `allow_stream_requests()` tests which ensures we don't
allow incoming streams on multipath tunnels (because we don't currently
support it).
This also changes `newcirc_ext` to return `ClientTunnel` instead of
`Arc<ClientTunell>` (we need to mutate `ClientTunnel` to manually set
`is_multi_path` on its inner `ClientCirc`).
|
| | | |
|
| | |
| |
| |
| | |
`as_single_circ()` returns an error for multipath tunnels.
|
| | |
| |
| |
| |
| |
| | |
Adapt all tests to use the new ClientTunnel.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
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]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
| |
| |
| | |
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]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to pull this off, some client => tunnel renaming needed to
happen including the comments.
The send_raw_msg() is an experimental and expert mode method that any
tunnel should have access to in order to be able to send whatever
message in whatever tunnel type.
No behavior changes.
Signed-off-by: David Goulet <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To use the functionality only allowed on single-circuit tunnels (such as
`extend*`), callers will have to call `ClientTunnel::as_single_circ()`
to obtain a handle to the underlying `ClientCirc`.
This is an opinionated design decision that goes against the plan from
[!2790]. It stems from my thinking that it would make more sense to keep
`ClientCirc`, than to merge it into `ClientTunnel`. If we merge the two,
many functions will need become fallible and less ergonomic, because the
user of `ClientTunnel` needs to know whether the `ClientTunnel` consists
of a single-circuit or not. Providing (fallible) access to the
underlying `ClientCirc` of the `ClientTunnel` seems simpler than the
alternative. That being said, I am open to switching back to the
original plan if this design turns out to be annoying to work with.
[!2790]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2790
|
