mirrors/arti.git/crates/tor-proto/src/client/reactor/control.rs, branch mainmirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=main2026-08-11T19:54:14Ztor-proto: box `CircParameters` in test-only `CtrlCmd::AddFakeHop`2026-08-11T19:54:14ZSteven Engleropara@torproject.org2026-08-11T19:49:43Zurn:sha1:632d287dca1518d907b06d16e322e458d4c21e56
This fixes a `clippy::large_enum_variant`.
tor-cell: rename `XonKbpsEwma` to `XonKBpsEwma`2026-07-30T21:34:23ZSteven Engleropara@torproject.org2026-07-30T21:01:27Zurn:sha1:0fecfa9a0102ff58676bcb0c5e36eed4996a68f4proto: log virtual hop additions at trace.2026-07-02T14:37:13ZNick Mathewsonnickm@torproject.org2026-06-09T18:09:30Zurn:sha1:3dd77d29dd163b22225b0b33b9c3c638a64a938d
We do something similar with non-virtual hops at !4076.
proto: Add crate-level exports for two extra stream types (fmt)2026-06-17T13:38:44ZGabriela Moldovangabi@torproject.org2026-06-17T13:31:26Zurn:sha1:d305c6c0a201703ce14fbcfdce1864aeda9cc8dctor-proto: move memquota stream account arg to last position2026-05-21T16:35:59ZSteven Engleropara@torproject.org2026-05-21T02:13:21Zurn:sha1:73088207825942721ec02ccec4d2424e688586f3
This better matches nearby code.
tor-proto: move more stream queue init to reactor2026-05-21T16:35:59ZSteven Engleropara@torproject.org2026-05-21T01:57:13Zurn:sha1:e62d824614fc501d21f6b58f1e98346bf495e1e3
Previously when initializing a stream, we constructed most of the
stream-related queues outside of the reactor and passed the relevant
halves of the queues (senders or receivers) into the reactor.
A downside of the above approach is that the reactor may be better
informed about what queues to construct, and how to construct them. For
example the reactor knows what type of flow control that the hop is
using, so it knows whether we need queues for passing rate limits and
drain rates for XON/XOFF flow control.
This commit moves the construction of these queues into the reactor and
passes the relevant halves out of the reactor. In the future we can make
better decisions about which queues are needed depending on the flow
control method used instead of always constructing them (see arti#2068).
Reviewing with `--color-moved` might be helpful as a few lines have been
moved.
tor-proto: add `ReactorStreamComponents` to bundle return vals2026-05-21T01:52:49ZSteven Engleropara@torproject.org2026-05-20T19:29:58Zurn:sha1:2801a1b30f50488ca79bbe21d3061b07fe40b945tor-proto: move stream incoming queue init to reactor2026-05-21T00:36:59ZSteven Engleropara@torproject.org2026-05-12T22:36:57Zurn:sha1:be505ab176da88dd8cea7e3a42530d81fb0267b5
The stream queue length (for messages incoming from the Tor network)
depends on the type of flow control we're using for the hop. Currently
we construct the stream queue outside of the circuit reactor, but we
don't have the flow control information here.
Instead of constructing the stream queue outside of the reactor and
passing the sender into the reactor, we construct the stream queue
inside of the reactor and pass the receiver out of the reactor.
tor-proto: clean up return type of `Circuit::begin_stream()`2026-05-11T21:06:25ZSteven Engleropara@torproject.org2026-05-11T20:40:46Zurn:sha1:2719019310d76aafebe6b33b01512d09a55eeae3tor-proto: reorg error handling for BeginStream reactor cmd2026-05-11T20:44:42ZSteven Engleropara@torproject.org2026-05-11T20:31:51Zurn:sha1:22ba049e5b89bb3e0c14798ee24b6f33c30883ac