mirrors/arti.git/crates/tor-proto/src/stream.rs, branch arti-v1.7.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.7.02025-10-21T17:08:13Zproto: Move StreamMpsc{Sender,Receiver} to stream module2025-10-21T17:08:13ZGabriela Moldovangabi@torproject.org2025-10-21T17:08:13Zurn:sha1:4e824c7e2d654d9fb0fa4f0cabd8d8c7eed7bd61
These will be shared with the relay code.
proto: Move dumb pipes to top-lvl stream module2025-10-21T17:08:13ZGabriela Moldovangabi@torproject.org2025-10-21T17:08:13Zurn:sha1:86a5d8ee712a57955f5256ac5af2c2f044a43a61proto: Move IncomingDataCmdChecker to top-level stream module.2025-10-16T13:47:15ZGabriela Moldovangabi@torproject.org2025-09-30T00:04:25Zurn:sha1:869d1243cd3b17820fe234b3047e0e2fd8cc406b
This will be used by relays too (for validating incoming messages on
streams).
This is just code motion, so it's best reviewed with `--color-moved`.
proto: Move cmdchecker under top-level stream module.2025-10-16T13:47:15ZGabriela Moldovangabi@torproject.org2025-09-29T17:29:39Zurn:sha1:a3fc3c534db4d4782c22ca2bcbd947812b77bd44
The CmdChecker will be used by relays too, so I am moving it to the
shared `stream` module.
proto: Move flow_ctrl module under stream.2025-10-07T09:31:47ZGabriela Moldovangabi@torproject.org2025-10-01T16:33:10Zurn:sha1:3fcc257517dd8ba4b111364b09237d547ce3c836
This will be used by exits too, so I am moving it out of `client`.
proto: Add a top-level stream module.2025-10-07T09:31:47ZGabriela Moldovangabi@torproject.org2025-09-08T13:47:30Zurn:sha1:6a75d959b97a203d8970933e7c2758581d3c7d1e
This will house the implementation-agnostic stream types and
functionality.
proto: Move the `stream` module under `client` (breaking).2025-08-18T16:09:04ZGabriela Moldovangabi@torproject.org2025-08-18T15:52:38Zurn:sha1:702e7276898d3f31e22033c5b64fea91703f3701
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
proto: Rename the `tunnel` module to `client`.2025-08-18T16:09:04ZGabriela Moldovangabi@torproject.org2025-08-18T15:14:43Zurn:sha1:1ee26f2168ee2dede8ab993ef57435334e9efabe
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
conflux: Adjust docs and fix doc links.2025-08-05T18:23:02ZGabriela Moldovangabi@torproject.org2025-07-21T16:29:23Zurn:sha1:b7dffdcd6e8e36882320a034a702ffe5c9909682tor-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.