mirrors/arti.git/crates/tor-proto/src/stream, branch arti-v1.2.7

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.

flow-control: document idea for making more robust

2024-08-21T21:53:08Z

From

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.

Fix clippy::doc_lazy_continuation

2024-07-08T10:36:25Z

proto: Try to clarify why StreamReader has a StreamTarget.

2024-05-29T11:28:05Z

proto: Improve documentation about DataStream lifetimes and closing

2024-05-29T11:28:05Z

In particular, clarify that dropping the DataWriter on its own does nothing unless the DataReader is also dropped. Related to #1368.

proto: Make DataWriter::close actually do something.

2024-05-29T11:28:01Z

Previously we had a bug where `::close` (or `shutdown` in tokio-land) would not actually have any effect. It _would_ drop the `StreamTarget` held by the `DataWriter`, but since the `DataReader` also held a `StreamTarget`, the MPSC channel would not get closed, and the circuit reactor would not realize that the stream wanted to shut down. Now we use `mpsc::Sender::close_channel` to make our closes effectual. Closes #1368. Additionally, we fix a bug where `poll_close()` never actually did anything if the buffer had nothing in it when it was called. Previously, `poll_flush_impl()` would exit immediately if it had no data to flush. That isn't what we want when we are closing!

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.

proto: Fix compilation with stream-ctrl but not experimental-api.

2024-05-14T12:04:03Z

proto: Expose wait_for_connection as a part of the DataStream API.

2024-05-09T20:34:17Z