mirrors/arti.git/crates/tor-proto/src/stream/incoming.rs, branch arti-v1.7.0

proto: Rename data cmd checkers to {Inbound,Outbound}DataCmdChecker

2025-10-16T13:47:15Z

The previous "incoming" terminology was rather ambiguous. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337

proto: Move IncomingDataCmdChecker to top-level stream module.

2025-10-16T13:47:15Z

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`.

proto: Move the `stream` module under `client` (breaking).

2025-08-18T16:09:04Z

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.

proto: Rename the `tunnel` module to `client`.

2025-08-18T16:09:04Z

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.

Switch Cargo.toml files to edition 2024.

2025-08-07T15:28:36Z

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.

proto: Move ClientCirc stream functions to ClientTunnel

2025-08-05T18:23:02Z

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

tor-proto: add the `XonXoffReader` and connect it to the reactor

2025-07-17T18:01:47Z

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.

tor-proto: combine some objects into a `StreamComponents`

2025-07-15T05:33:24Z

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.

tor-proto: rename `StreamReader` to `StreamReceiver`

2025-06-26T17:01:22Z

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.

tor-proto: pass the time provider to the `DataWriter`

2025-06-05T15:14:50Z