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

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

Add a RelayCellFormat argument to encode().

2025-04-16T14:58:49Z

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.

squash! Upgrade rand dependency to 0.9.

2025-03-18T16:09:44Z

- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`

tor-proto: Add a tunnel module.

2025-02-20T20:15:12Z

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

tor-proto: Put a StreamAccount in DataStream etc.

2024-10-03T14:10:47Z

Some HasMemoryCost impls in tor-proto

2024-10-02T18:11:26Z

extract tor_async_utils::oneshot into ::oneshot-fused-workaround

2024-08-28T14:27:46Z

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.