aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit/reactor
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: disable flowctrl sidechannel mitigations for relaysSteven Engler7 days1-3/+7
| | | | | | | | The end result should be: 1. outgoing streams - enable sidechannel mitigations 2. incoming hs streams - enable sidechannel mitigations 3. incoming exit streams - disable sidechannel mitigations
* tor-proto: add `StreamHandler::flowctrl_sidechannel_mitigations()`Steven Engler7 days1-0/+4
|
* proto: Add {backward|forward} prefix to circ_id in logsDavid Goulet2026-08-034-10/+10
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename uniq_id to circ_unique_id mostly in loggingDavid Goulet2026-08-034-11/+11
| | | | | | | | | We have decided that instead of "uniq_id" in logging, we'll use the "<domaine>-[<type>]-id" syntax to indicate who is that unique ID. This commit only renames circuit's unique ID to "circ_uniq_id". Signed-off-by: David Goulet <[email protected]>
* proto: Log both UniqId and CircId when possibleDavid Goulet2026-08-035-17/+67
| | | | | | | | | | This commit only affects logging. Whenever possible, log both the UniqId and CircId. This also changes the log lines which is now "uniq_id=" and "circ_id=" as the UniqId is internal and circ_id (CircId) is protocol level. Signed-off-by: David Goulet <[email protected]>
* proto: Rename CircId and UniqId variable nameDavid Goulet2026-08-031-1/+1
| | | | | | | | | | | | | | | A CircId is now a circ_id and a UniqId is a unique_id so we stop confusing them in the code. Furthermore, channel_id that are CircId are now circ_id. Channel IDs are different and encoded internally into a UniqId. This is the first step to clarify semantic before we change the logging to log both unique ID and circ ID. No behavior change. Signed-off-by: David Goulet <[email protected]>
* proto: Include the actual cell command in an error messageGabriela Moldovan2026-07-231-3/+5
| | | | | | | This can happen if we get an unexpected BEGIN_DIR/RESOLVE too, so we can't hard-code "BEGIN" in the error message. Context: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4230#note_3439258,
* proto: Remove feature-gating from CircHop::handle_msg()Gabriela Moldovan2026-07-231-3/+1
| | | | | | | | | | | | | | | This feature-gating has been a source of confusion, and it unnecessarily complicates the stream message handling flow. I've previously argued in favour of keeping it, in the spirit of a belt and braces approach to message validation, but I've been convinced that in this particular case, the feature-gate is more trouble than it's worth. What makes things worse is that the `CircHop::handle_msg()` function was designed poorly (by yours truly). I plan on refactoring it at some point, hopefully soon. There is a TODO about this below its doc comment.
* proto: Add TODO about the eventual client-side reactor rewriteGabriela Moldovan2026-07-021-0/+10
| | | | | See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4188#note_3432579
* proto: Allow BeginDir and Resolve messages in the stream reactor (fmt)Gabriela Moldovan2026-07-011-1/+3
|
* proto: Allow BeginDir and Resolve messages in the stream reactorGabriela Moldovan2026-07-011-9/+30
| | | | | | | Previously, these would fail to parse, because the (WIP) stream reactor assumed all streams would be exit (BEGIN) streams. Closes #2613
* proto: Add expect(unused) where neededGabriela Moldovan2026-06-291-0/+1
| | | | | | | | | | | Now that relays no longer use `CtrlCmd::AwaitStreamRequests`, some of these fields are unused. I'm leaving them in for now, but we should remove them if they're still unused after we finish the circ reactor impl. I'm not removing `AwaitStreamRequests`, because it will be needed by onion services, when we replace the old client circuit reactor with the new one.
* proto: Support passing a stream request filter to the reactorGabriela Moldovan2026-06-291-1/+47
| | | | | | | | | Relay circuits always need a filter, so it's best to set it via the constructor. Part of #2582 Closes #2577
* proto: Rename LocalApplicationStream for clarityGabriela Moldovan2026-06-231-4/+4
| | | | | See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4139#note_3429586
* proto: Rework error handling in `HopMgr::get_or_spawn_reactor()`Gabriela Moldovan2026-06-231-12/+7
| | | | | | | | | | This reworks `get_or_spawn_reactor()` to return `Error` instead of `ReactorError`. The main change here is that we now have a dedicated `Error::Spawn` variant for `SpawnError`s, instead of mapping these to `ReactorError` (which actually triggers a clean shutdown, which is not quite what we want here).
* proto: Simplify StreamEvent::LocalStreamClosed (fmt)Gabriela Moldovan2026-06-231-1/+6
|
* proto: Simplify StreamEvent::LocalStreamClosedGabriela Moldovan2026-06-231-15/+4
| | | | | This doesn't need to contain the `CloseStreamBehavior` or `TerminateReason`, because we always use the same ones.
* proto: Rename StreamEvent::Closed to LocalStreamClosedGabriela Moldovan2026-06-231-5/+5
| | | | | | | I realized the previous naming was ambiguous. Hopefully this makes it clear that this `StreamEvent` triggers when the MPSC channel connecting the reactor to the local application stream (for example the local TCP connection of the stream, in the case of exit streams) is dropped.
* proto: Implement ClosePendingStream in the stream reactorGabriela Moldovan2026-06-233-5/+40
| | | | Closes #2590
* proto: Add a helper function for handling closed streams (fmt)Gabriela Moldovan2026-06-231-10/+10
|
* proto: Add a helper function for handling closed streamsGabriela Moldovan2026-06-231-6/+22
| | | | This will soon be reused for implementing `CtrlMsg::ClosePendingStream`.
* proto: Add a new StreamReactor control message for closing streamsGabriela Moldovan2026-06-231-3/+25
| | | | | | | | | | | | | | | This will be sent by the FWD reactor. Essentially, this going to be the final control message in the chain `IncomingStream::reject()` -> `RelayCirc::reject()` -> `forward::CtrlCmd::ClosePendingStream`-> `HopMgr::close_pending()` -> `stream::CtrlCmd::ClosePendingStream` -> stream gets removed from the stream map, END sent Part of #2590
* proto: Update docs to clarify where the StreamReactor cell sender isGabriela Moldovan2026-06-231-1/+2
|
* proto: Add a control message for closing pending streams (fmt)Gabriela Moldovan2026-06-231-3/+4
|
* proto: Add a control message for closing pending streamsGabriela Moldovan2026-06-231-1/+40
|
* proto: Replace StreamMsg with a new CtrlMsg typeGabriela Moldovan2026-06-234-26/+32
| | | | | | | This replaces the `StreamMsg` `StreamReactor` sender with a new `CtrlMsg` type. This `CtrlMsg` currently only has a `DeliverStreamMsg` variant (which is the same as the old `StreamMsg` type), but will soon grow another variant, for terminating a stream.
* tor-proto: have `StreamReqInfo` store a `ReactorStreamComponents`Steven Engler2026-05-211-4/+1
|
* tor-proto: move memquota stream account arg to last positionSteven Engler2026-05-211-1/+1
| | | | This better matches nearby code.
* tor-proto: clean up `CIRCUIT_BUFFER_SIZE`Steven Engler2026-05-211-7/+0
|
* tor-proto: move more stream queue init to reactorSteven Engler2026-05-211-28/+8
| | | | | | | | | | | | | | | | | | | | 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 valsSteven Engler2026-05-201-2/+2
|
* tor-proto: move stream incoming queue init to reactorSteven Engler2026-05-201-11/+3
| | | | | | | | | | | 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 changesSteven Engler2026-04-071-6/+9
| | | | I think this makes the code a little easier to follow.
* proto: Move handle_unrecognized_cell() out of ForwardHandlerGabriela Moldovan2026-03-251-12/+1
| | | | | | | | | | 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_EARLYGabriela Moldovan2026-03-251-0/+1
| | | | Closes #2417
* Fix typosTobias Stoeckmann2026-03-242-2/+2
| | | | Typos found with codespell
* proto: Replace TimeoutEstimator with opaque handlerGabriela Moldovan2026-03-192-49/+12
| | | | | | | | | | | | | | | This replaces the client-specific half-stream expiry calculation from the stream reactor (which is meant to be implementation agnostic) with a call to the new `StreamHandler::halfstream_expiry()`, which abstracts away the implementation-specific half-stream expiry calculation (for example, on the client-side, the calculation takes into account the CBT, which we don't have on the relay side). Note that there is currently no `StreamHandler` implementation on the client-side (because we haven't ported the client circuit reactor to the new reactor yet). Closes #2410
* proto: Add a trait for customizing StreamReactor behaviorGabriela Moldovan2026-03-191-0/+13
| | | | | This will enable us to handle half-stream expiry differently on the client side vs the exit side.
* Merge branch 'circ-react-logs' into 'main'David Goulet2026-03-161-1/+16
|\ | | | | | | | | proto: Add more logging to the new circuit reactors See merge request tpo/core/arti!3776
| * proto: Add more logging to the new circuit reactorsGabriela Moldovan2026-03-121-1/+16
| |
* | Fix word duplicate typosTobias Stoeckmann2026-03-151-1/+1
|/
* proto: Rename CircSyncView to CircHopSyncView (fmt)Gabriela Moldovan2026-02-161-1/+1
|
* proto: Rename CircSyncView to CircHopSyncViewGabriela Moldovan2026-02-161-3/+3
| | | | And update the docs
* proto: Use CircSyncView in the new circuit reactorGabriela Moldovan2026-02-161-13/+7
| | | | | Now that CircSyncView no longer needs to know the total number of streams, we can use it in the new per-hop stream reactor design.
* Revert "proto: Add a new ToRelayMsg util"Gabriela Moldovan2026-02-122-5/+2
| | | | | | | | | | This reverts commit 04ab3cd848d7977baf58dd64ebfcad6aa54ecb17. Reverted because we no longer need to "peek" into the opaque `CircChanMsg` of a circuit reactor: now the implementation-dependent part of the reactor is in charge of handling the channel messages, and extracting `Relay` objects out of RELAY/RELAY_EARLY cells, which then get processed in the base reactor.
* proto: Move decode_relay_cell() out of ForwardHandlerGabriela Moldovan2026-02-121-16/+0
| | | | | | | | This doesn't need to be part of the `ForwardHandler` trait anymore, because the base reactor no longer calls it directly (instead implementations are supposed to handle it internally). No functional changes here, just code motion.
* proto: Forbid EXTEND2 from RELAY cellsGabriela Moldovan2026-02-121-1/+2
| | | | Closes #2339
* proto: Pass the early flag to handle_relay_msg() (fmt)Gabriela Moldovan2026-02-121-1/+3
|
* proto: Pass the early flag to handle_relay_msg()Gabriela Moldovan2026-02-121-3/+5
| | | | | Needed because some messages are handled differently depending on the cell type they originated from (RELAY vs RELAY_EARLY).
* proto: Overhaul forward cell handlingGabriela Moldovan2026-02-121-13/+37
| | | | | | | | | | | This pushes the RELAY/REALY_EARLY handling inside `handle_forward_cell()`, which now decodes the relay cells and * handles them internally, if they are unrecognized (`handle_unrecognized_cell()`), or * returns them back to the base reactor if they are recognized (RELAY and RELAY_EARLY cells are handled the same way by the base reactor)
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:55:09 +0000