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

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

tor-proto: Push stream message parsing into the stream objects.

2023-02-15T15:48:19Z

This closes #525, and ensures, at last, that we don't parse any message that we wouldn't accept.

tor-cell: Rename RelayMsg and RelayCell-related types.

2023-02-07T21:03:14Z

Thanks to rust-analyzer for making this simple.

impl Debug for DataStream (and its components)

2022-02-24T17:49:34Z

My proximate motivation is that tls-api wants its inner streams to be Debug. But in general, I agree with the Rust API Guidelines notion that almost everything should be Debug. I have gone for the "dump all the things" approach. A more nuanced approach would be possible too.

Make tor-proto::Error implement HasKind.

2022-02-15T14:41:47Z

This took some refactoring, and gave an opportunity to notice a few error variants that weren't being used, or didn't mean what they said on the tin.

Get rid of unbounded stream sender, and RawCellStream

2021-11-12T15:04:27Z

Previously, the reactor would use an `UnboundedSender` to send things to the `RawCellStream`, in order that the reactor wouldn't block if you failed to read from the latter. This is bad, though, since it means people can just run us out of memory by sending lots of things. To fix this, we make the new `StreamReader` type (which does the reading parts from `RawCellStream`) keep track of the stream's receive window and issue SENDMEs once *it* has consumed enough data to require it, thus meaning that we shouldn't get sent enough data to fill the channel between reactor and `StreamReader` (and, if we do, that's someone trying to flood us, and we abort the circuit). As hinted to above, the `RawCellStream` was removed and its reading functionalities replaced by `StreamReader`; its writing functionalities are handled by `StreamTarget` anyway, so we just give out one of those for the write end. This now means we don't need any mutexes! note: this commit introduces a known issue, arti#230