| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
This already returns `()` in the `Ok` case.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| | |
|
| | |
|
| |
|
|
|
| |
The `CircHopSyncView` is now the view of a hop, not of the whole
circuit.
|
| |
|
|
| |
And update the docs
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The previous "incoming" terminology was rather ambiguous.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337
|
| |
|
|
|
|
|
| |
This will be used by relays too (for validating incoming messages on
streams).
This is just code motion, so it's best reviewed with `--color-moved`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
As we continue adding more functionality to streams like flow control,
we'll have more objects to pass around. This tries to group them
together.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In rust, the typical nomenclature is to use "receiver" for channels, and
"reader" for byte streams. For example `mpsc::Receiver` for something
that returns objects and `AsyncRead` for something that reads bytes.
Since we also have a `DataReader` for reading bytes, I think renaming
this from `StreamReader` to `StreamReceiver` better describes what it is
(it's not a "reader" in the typical `Read`/`AsyncRead` sense).
This type is public in the API, but is not actually accessible. As far
as I can tell there is no way to construct it or access it.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This will let us actually _send_ messages in the right format.
This approach is not ideal for packed/fragmented messages;
they will need a separate RelayCellEncoder.
part of #1944.
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| | |
|
| |
|
|
| |
(Doing this to prevent us having two structs with the same name.)
|
| |
|
|
|
|
|
| |
Based on designs in #1124.
Note that there is a TODO here about a hack I had to do to appease
the borrow checker.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Prop 340:
https://spec.torproject.org/proposals/340-packed-and-fragmented.html
This updates the decoding API to support multiple versions of the relay
cell encoding, including the new encoding proposed in prop340 that
supports relay message packing and fragmentation.
This commit doesn't actually add support for that new encoding yet.
|
| |
|
|
|
| |
For consistency with the terminology proposed in
https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
|
| |
|
|
|
|
|
| |
We never actually constructed these before, but now we enforce it at
the API level.
Part of #1269.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is pure renaming, done automatically with rust-analyzer.
Comment fixes and other cleanups will be in the subsequent commits.
We're doing this renaming because we need a name for
the combination of a `RelayMsg` and an `Option<StreamId>`
that we use when we have a `RelayMsg`
we intend to route to a given stream or circuit internally.
Previously we called this a `RelayCell`,
but that name was already somewhat inaccurate,
and will become _very_ inaccurate with the arrival of prop340,
which breaksthe 1:1 relationship between relay cells
and relay messages.
(If we didn't do this renaming now, we'd soon be making
the relationship between `UnparsedRelayCell`and `RelayCell`
many-to-many, which would be ridiculous and confusing.)
The `RelayMsgOuter` name is a placeholder:
We expect that we'll want to rename this type,
and may also want to rename `RelayMsg`,
and unify our vocabulary in other areas too.
But such a renaming will have to wait
for a larger discussion affecting the specifications,
so that we can use the same vocabulary everywhere.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Because dropping a `StreamTarget` causes the circuit reactor to send
an End, the previous do-nothing implementation of `discard()` wasn't
sufficient to cause the request to be ignored without sending an
End.
This commit modifies our "close pending stream" behavior to only
optionally send an End message. To avoid confusion, I'm using a new
`CloseStreamBehavior` enum rather than an `Option<End>`, since we
had previously used `None` in some cases to indicate a default
(misc) end message.
|
| | |
|
| |
|
|
|
|
| |
Now that every state-change function consumes the IncomingStream,
there is no longer any reason to keep track of an internal state
enum.
|
| | |
|
| |
|
|
|
| |
Now that IncomingStream doesn't implement Drop, we can just
destructure it.
|
| |
|
|
|
| |
Since dropping a StreamTarget will send an End, we don't need
to call reject_internal in this case.
|
| |
|
|
|
|
|
|
|
| |
It turns out that we can make `IncomingStream::reject()` consume
self, thus making it impossible to hit the double-close error
from outside the `tor-proto` crate.
Also, we rename `StreamTarget::close()` to `close_pending()` to
better reflect its limited applicability.
|
| |
|
|
|
| |
This should be smaller and faster than vec, and save some
allocations. It could also avoid a tiny sidechannel.
|
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| |
|
|
| |
These functions only ever return `Bug` errors.
|
