| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
We have decided that instead of "uniq_id" in logging, we'll use the
"<domaine>-[<type>]-id" syntax to indicate who is that unique ID.
This commit only renames circuit's unique ID to "circ_uniq_id".
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A CircId is now a circ_id and a UniqId is a unique_id so we stop
confusing them in the code.
Furthermore, channel_id that are CircId are now circ_id. Channel IDs are
different and encoded internally into a UniqId.
This is the first step to clarify semantic before we change the logging
to log both unique ID and circ ID.
No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Circuit IDs (UniqId) are displayed as "Circ <x>.<y>".
Prior to this MR, these TunnelScopedCircId's were displayed as
"Circ <t>.<x>.<y>" where t is the integer tunnel ID. This made corresponding
logs a bit confusing as to why some "Circ" identifiers had two parts and
some have three, and didn't make clear that the "<x>.<y>" part of the latter
were comparable with the two-part UniqIds.
The previous commit effectively changes the latter to
"Circ Tunnel <t>.<x>.<y>", which is still a bit confusing.
This commit changes the display of TunnelScopedCircId's to "Circ <x>.<y>
(Tunnel <t>)", which makes the distinction between the circuit and
tunnel IDs clearer.
|
| |
|
|
|
|
| |
This is akin to how circuit `UniqId`'s are prefixed with "Circ", and
helps clarify logs where it isn't always clear from context whether a
tunnel ID or circuit ID is being displayed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `TunnelId*` types will be reused in the relay reactor (exit relays
need to have the concept of a "tunnel ID" because of conflux).
Now the `relay::reactor` module only has a single import from `client`
(for the `unwrap_or_shutdown` helper, which we should be able to remove
soon). From now, we will avoid importing anything from `client` in the
`relay` module, and instead prefer refactoring the code as needed (to
pull the implementation-agnostic parts outside of `client`).
This commit has no functional changes, just code motion.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Part of #1447
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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]>
|
| |
|
|
| |
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
|
| |
|
|
|
| |
Since these will be negotiated (or determined as part of negotiation)
they belong in HopSettings.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The idea here is that the reactor builds an `XonXoffReaderCtrl` for the
new stream, and the `XonXoffReaderCtrl` can receive notifications from
the reactor's `StreamFlowControl`. The `XonXoffReaderCtrl` can be
combined with any `AsyncRead` to build a `XonXoffReader`, essentially
wrapping the `AsyncRead` with a type that handles XON/XOFF flow control.
Essentially, the reactor gives you a type that allows you to add
XON/XOFF flow control support to any `AsyncRead`.
We will add this `XonXoffReader` to the `DataReader` in a future commit.
|
| |
|
|
|
| |
Nothing actually causes an XON to be sent yet. But this adds the code so
that anything holding the `StreamTarget` can request to send an XON.
|
| |
|
|
|
|
|
|
| |
This allows us to extend the command to implement different flow control
methods. We could add new command variants for new flow control methods
instead, but I think it makes sense to have them be a single command as
they will always have a stream ID / hop location in common. This also
helps us keep the flow control logic in one place.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are some pros/cons to this change:
Pros:
1. The only remaining `await` in `StreamReceiver::recv` is for polling
the receiver, which means we can turn the `StreamReceiver` into a
`Stream` in a future commit.
2. We won't block the user from receiving messages while we wait for the
circuit reactor to receive our SENDME message and send it on the
outgoing channel.
3. The `StreamReceiver` doesn't really care if it can't send the SENDME.
There isn't anything it can do, the circuit hop can go away for
external reasons like a DESTROY message, and we still want to return
all queued messages to the user anyways.
Cons:
1. If the `StreamReceiver` sends a SENDME request to the circuit
reactor, and the circuit reactor fails to send the SENDME, there's no
good way for the reactor to communicate this back to the
`StreamReceiver`.
|
| |
|
|
|
|
|
|
|
|
|
| |
This requires some changes to the tor-proto crate to handle the inbound
TargetHop from the HS subsystem and then resolve it into a HopNum for a
single circuit.
It is expected that this will change again with Conflux to only use
HopLocation internally in a Tunnel and then use HopNum into a Circuit.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This is in the spirit of making everything going inbound the tor-proto
crate to use a TargetHop.
This becomes much easier for the HS subsystem as it only uses the last
hop for its conversation and setup.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Quick helper as within the tor-proto crate, we sometimes have to quickly
get a TargetHop.
This will come handy with the message handler used by the Conversation
object that the HS subsystem uses.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is about to be used outside of tor-proto. It is part of the work to
remove the use of HopNum outside tor-proto.
The rules are:
- Inbound requsest to the tor-proto crate, TargetHop must always be
used.
- Within tor-proto, TargetHop is resolved into a HopLocation which is
more precise and based on the tunnel circuit(s).
This is another piece that Conflux will require considering that a
Tunnel might have multiple circuits in the future.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Closes #1999
|
| |
|
|
|
|
| |
This type will help produce better logs (logging just the circuit ID
would make it impossible to correlate said circuit with the tunnel it
belongs to).
|
| |
|
|
|
|
|
|
|
|
| |
Currently, a tunnel is uniquely identified by the `UniqId` of the first
circuit added to the tunnel. This works, but the double-meaning of the
`UniqId` is bound to cause confusion in the future (because it blurs the
distinction between tunnels and circuits).
This introduces a new `TunnelId` type which will replace `UniqId` in the
tunnel reactor.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since v1 cells have a longer tag, they can fit less data into a
single cell. Ah well, that's the cost of improved security.
The code in data.rs is a little wonky, in that it currently requires
its buffer to be exactly the maximum size for a data cell. We have
a TODO about fixing that in the future, but for now I've moved it to
use a boxed slice rather than a boxed array.
Part of #1944.
|
| | |
|
| |
|
|
|
|
|
|
| |
This doesn't yet change the public API, it just begins the work of
plumbing these around throughout `ClientCirc`, `Reactor`, etc.
This can't be broken up into smaller commits without causing build
failures.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is mostly code motion + some visibility adjustments.
Moving all of these outside of `reactor` makes it easier to see which
parts are internal vs which are accessed by the reactor. It also helps
us enforce/audit invariants such as 'there should be no contention on
the `CircHop::map` mutex' (the stream map is now private to
`reactor::circuit`, and therefore nothing inside `reactor` will be
directly accessing it).
|
| | |
|
| | |
|
|
|
Move StreamTarget to the tunnel module and the circuit module.
From now on streams will be implemented on tunnels, not circuits.
This moves `StreamTarget` to the tunnel module. A future change will
replace `ClientCirc` with `ClientTunnel` inside `StreamTarget`.
This is mostly code motion, best reviewed with `--color-moved`.
Signed-off-by: David Goulet <[email protected]>
|
