mirrors/arti.git/crates/tor-proto/src/circuit/msghandler.rs, branch arti-v1.4.0

proto: Remove ConversationInHandler

2025-02-04T16:08:43Z

It is unused but most importantly it allows any RELAY cell to be sent from anywhere in the code which is really not desirable because it is skipping congestion control. It also allows us to remove the `control_tx` from the reactor which is one less channel to track/understand/think about. This opens up the door to all sorts of problems especially side channel that can be exploited if we are not careful. We can always bring this back if we need it but for now, it is unused and allows us to remove the `CtrlMsg::SendRelayCell` control message. No code behavior change. Signed-off-by: David Goulet

tor-proto: Rewrite circuit reactor run_once() loop to use select!.

2025-01-29T14:34:58Z

This rewrites the circuit reactor main loop to use `select_biased!` to poll multiple futures simultaneously. The new `run_once()`, like the old, first waits for an initial `CtrlMsg::Create`. Then, it uses a `select_biased!` to poll the `chan_sender` sink and shutdown channel for readiness. When the channel sink is ready, we poll the `control` and `input` channels like before, as well as the new `ready_streams` `Stream` (`ready_streams` is a `futures::Stream` that replaces the previous `send_outbound()` function). Most of the implementation remains unchanged, except the `handle_input`, `handle_cell` and `handle_control` functions no longer send anything on the `chan_sender` channel. Instead, they may do some (synchronous) processing, and send instructions for the remaining work that needs to be done (for example, for writing the cell to the `chan_sender` channel). These instructions are handled at the end of `run_once()`, and are encoded in the `RunOnceCmdInner` enum. What this change does **not** do: * the control channel *still* bypasses congestion control. We could fix this by making the various reactor functions send the `RunOnceCmdInner` commands to `run_once()` via a channel (instead of returning them). This would enable the reactor to stop reading the commands (except for handle `Sendme`, which would be handled separately) if it's blocked on congestion control.

Rename UnparsedRelayCell -> UnparsedRelayMsg

2024-03-12T15:58:12Z

For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253

Rename {Any}RelayCell to {Any}RelayMsgOuter

2023-12-14T16:56:58Z

This commit is pure renaming, done automatically with rust-analyzer. Comment fixes and other cleanups will be in the subsequent commits. We're doing this renaming because we need a name for the combination of a `RelayMsg` and an `Option` that we use when we have a `RelayMsg` we intend to route to a given stream or circuit internally. Previously we called this a `RelayCell`, but that name was already somewhat inaccurate, and will become _very_ inaccurate with the arrival of prop340, which breaksthe 1:1 relationship between relay cells and relay messages. (If we didn't do this renaming now, we'd soon be making the relationship between `UnparsedRelayCell`and `RelayCell` many-to-many, which would be ridiculous and confusing.) The `RelayMsgOuter` name is a placeholder: We expect that we'll want to rename this type, and may also want to rename `RelayMsg`, and unify our vocabulary in other areas too. But such a renaming will have to wait for a larger discussion affecting the specifications, so that we can use the same vocabulary everywhere.

Convert StreamId to NonZeroU16

2023-10-25T20:34:55Z

tor-proto: Add ClientCirc::start_conversation().

2023-08-04T12:08:31Z

This will enable hidden services to send `RENDEZVOUS1` messages to the `N`th hop of the circuit rather than the `N + 1`th virtual one (which can only used after the client and service have completed the introduction handshake). This also deprecates `start_conversation_last_hop`. Closes #959

tor-proto: run rustfmt

2023-06-30T17:43:20Z

tor-proto conversation API: Provide ConversationInHandler

2023-06-30T17:43:20Z

tor-proto circuit: Plumb async Context through

2023-06-30T17:28:41Z

handle_msg is going to want this in a moment.

tor-proto conversation API: Soften a warning

2023-06-30T17:28:41Z

If the circuit is just being used by us (which is likely, if we're using this API) then the only reactor we're blocking is our own.