mirrors/arti.git/crates/tor-proto/src/stream.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: add dedicated types for the incoming stream queue

2025-07-16T17:36:43Z

XON/XOFF flow control will want to know how many data bytes are queued on a stream, so the new types track that.

tor-proto: rename `StreamSendFlowControl` and related changes

2025-07-15T05:33:24Z

The plan is to use `StreamSendFlowControl` (now `StreamFlowControl`) for both outgoing and incoming directions, so a name change is needed. This also updates some comments, and renames some related struct fields that have the word "send" in them.

tor-proto: establish channel for rate limit updates

2025-07-07T17:12:05Z

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: 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

proto: Rename DataStreamCtrl to ClientDataStreamCtrl

2025-01-30T16:11:01Z

The API for this type, and the fact that it implements ClientStreamCtrl unconditionally, means that it is only for client DataStreams.

tor-proto: Encapsulate flow-control

2024-08-13T19:46:46Z

Encapsulate flow-control into a separate object that partially abstracts away the difference between window-based (legacy) flow control and xon-based (prop324) flow control.

Add an IncomingStreamRequestFilter to check early properties

2024-03-26T16:55:05Z

Based on designs in #1124. Note that there is a TODO here about a hack I had to do to appease the borrow checker.

tor-proto: Add IncomingCmdChecker for IncomingStream.

2023-08-03T15:18:35Z