mirrors/arti.git/crates/tor-proto/src/stream, branch arti-v1.4.6mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.62025-07-17T18:27:25Ztor-basic-utils: add `assert_val_impl_trait!` macro2025-07-17T18:27:25ZSteven Engleropara@torproject.org2025-07-17T17:15:36Zurn:sha1:ad940e7327f6a64923fe4316500bfaaba26bafebtor-proto: replace `DataReader`2025-07-17T18:02:07ZSteven Engleropara@torproject.org2025-07-17T07:19:38Zurn:sha1:66eec4843d37547c2e32e8f2e66fdadd999d8bff
`DataReader` -> `DataReaderInner`
`DataReaderNew` -> `DataReader`
This means that the `DataReader` now supports XON/XOFF flow control
using the `XonXoffReader`.
This means that it can receive requests for a new drain rate from the
reactor, and can send the new drain rate to the reactor once there is no
more stream data queued.
tor-proto: add `DataReaderNew`2025-07-17T18:02:07ZSteven Engleropara@torproject.org2025-07-17T06:59:32Zurn:sha1:14d95aee7878ce28cb7f8af539b2bca287e785fc
This will later become `DataReader`.
tor-proto: add `StreamReceiver::is_empty()`2025-07-17T18:02:07ZSteven Engleropara@torproject.org2025-07-17T06:44:01Zurn:sha1:bcb65bfbf5f198654eaee747dd680b99963c96cator-proto: add the `XonXoffReader` and connect it to the reactor2025-07-17T18:01:47ZSteven Engleropara@torproject.org2025-07-17T05:47:08Zurn:sha1:ac0a34306105bb003573a854c64eedc9cefac51e
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 plumbing for sending XON2025-07-17T18:01:47ZSteven Engleropara@torproject.org2025-07-16T19:48:06Zurn:sha1:4bcfcc3cae31f901e828369383e4660778eaa8c6
Nothing actually causes an XON to be sent yet. But this adds the code so
that anything holding the `StreamTarget` can request to send an XON.
tor-cell: add `FlowCtrlVersion::V0`2025-07-16T17:36:43ZSteven Engleropara@torproject.org2025-07-16T14:50:18Zurn:sha1:15422178d62506ad61b87a38f59cbc8536c5becdtor-proto: send XOFF messages when the queue grows too large2025-07-16T17:36:43ZSteven Engleropara@torproject.org2025-07-15T04:59:24Zurn:sha1:be5da87e8530a34a88db2a01b42a03431a9df8dbtor-proto: add dedicated types for the incoming stream queue2025-07-16T17:36:43ZSteven Engleropara@torproject.org2025-07-15T03:38:23Zurn:sha1:9067118cff859a40772462c20fd0bc44a5e8bedc
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: combine some objects into a `StreamComponents`2025-07-15T05:33:24ZSteven Engleropara@torproject.org2025-07-15T00:35:14Zurn:sha1:8268b4b6747ad1bfec5d1aa5d95e61248996990a
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.