mirrors/arti.git/crates/tor-proto/src/stream/raw.rs, branch arti-v1.4.5

tor-proto: rework `StreamReceiver` into a `futures::Stream`

2025-06-26T17:03:13Z

Having this be a `futures::Stream` makes it nicer to work with. For example we are able to remove a boxed future from `DataReaderState`, which should be better for performance and makes the code simpler. As mentioned in a previous commit when this type was named `StreamReader`, 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.

Make `StreamTarget::send_sendme` non-async

2025-06-26T17:03:08Z

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

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: made `StreamTarget::send_sendme` async and fixed a TODO

2025-03-24T13:59:09Z

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: Use congestion control in circuit reactor

2025-01-16T14:16:01Z

It is official, congestion control is now used at this commit by the circuit reactor making circuit/sendme.rs unused. Will be removed with another commit. Related #534 Signed-off-by: David Goulet

tor-proto: Introduce type aliases for stream queues

2024-10-02T14:15:56Z

This will make it easier to change their types.

proto: Try to clarify why StreamReader has a StreamTarget.

2024-05-29T11:28:05Z

proto: Explicitly enforce maxima on SENDME windows.

2024-05-14T14:36:05Z

No actual bug here, just technical debt: For `SendWindow`s, our tag system already ensured that we rejected any SENDME that didn't correspond to an appropriate drain. Still, it doesn't hurt to check. For `RecvWindow`s, it would have been a protocol violation if we ever did this, but it makes sense to make it an internal error if we try. Part of #1383.

Rename UnparsedRelayCell -> UnparsedRelayMsg

2024-03-12T15:58:12Z

For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253