mirrors/arti.git/crates/tor-proto/src/circuit/reactor, branch arti-v2.4.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.4.02026-05-21T16:35:59Ztor-proto: have `StreamReqInfo` store a `ReactorStreamComponents`2026-05-21T16:35:59ZSteven Engleropara@torproject.org2026-05-21T15:13:07Zurn:sha1:3ae295c879f773b8c6e922436fb96c020777555ator-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: clean up `CIRCUIT_BUFFER_SIZE`2026-05-21T16:35:59ZSteven Engleropara@torproject.org2026-05-21T02:56:49Zurn:sha1:6a9e07f8d42ebd6f698b0def041c5424cf2d42b8tor-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: small comment and variable name changes2026-04-07T19:30:16ZSteven Engleropara@torproject.org2026-04-07T19:29:01Zurn:sha1:9f438c50c9318c85991261e4223b78807b2f1bf5
I think this makes the code a little easier to follow.
proto: Move handle_unrecognized_cell() out of ForwardHandler2026-03-25T11:27:58ZGabriela Moldovangabi@torproject.org2026-03-25T10:45:03Zurn:sha1:88d7bc8fb0b39b37e950a30c2af7b139c5dadb91
The `ForwardHandler` trait is meant for implementation-dependent
functions that are called from the implementation-agnostic
`ForwardReactor`. Previously `handle_unrecognized_cell()` was called
directly by the generic `ForwardReactor`, but that's no longer the case,
so it doesn't belong in the trait anymore.
This commit is just code motion. Best reviewed with `--color-moved`
proto: Forward unrecognized RELAY_EARLY as RELAY_EARLY2026-03-25T11:27:58ZGabriela Moldovangabi@torproject.org2026-03-25T10:42:29Zurn:sha1:11462007836bf1d85eaeae7cac5814067b2ba712
Closes #2417
Fix typos2026-03-24T16:04:08ZTobias Stoeckmanntobias@stoeckmann.org2026-03-24T16:04:08Zurn:sha1:1fb2b8dd4aee7c943ce90d6631be473f2a296fe6
Typos found with codespell