aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay/reactor
Commit message (Collapse)AuthorAgeFilesLines
* proto: Move comment to the right placeDavid Goulet2026-08-031-3/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add {backward|forward} prefix to circ_id in logsDavid Goulet2026-08-033-6/+6
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename uniq_id to circ_unique_id mostly in loggingDavid Goulet2026-08-033-7/+7
| | | | | | | | | 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-033-15/+39
| | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | 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]>
* tor-proto: pass correct chan msg cmd to `decrypt_outbound()`Steven Engler2026-06-241-5/+7
| | | | | | | | | | Instead of converting the `RelayEarly` message to a `Relay` message, we add a new `RelayMaybeEarlyChanMsg` restricted message set that can hold either. Previously we were passing the wrong channel message command to `decrypt_outbound()`, which would cause the decryption to fail for relay crypto algorithms that use the command.
* proto: Remove TODOs about flushing pending dataGabriela Moldovan2026-05-262-8/+0
| | | | | | We decided the reactor is the wrong place to handle this. See discussion in #2490
* proto: Remove unused asyncGabriela Moldovan2026-05-201-3/+2
|
* proto: Make TRUNCATE trigger a proto violationGabriela Moldovan2026-05-201-5/+5
|
* proto: Add a comment clarifying why we don't need to propagate DESTROYGabriela Moldovan2026-05-201-0/+7
|
* proto: Adjust DESTROY-related logs in the backward reactorGabriela Moldovan2026-05-201-2/+6
| | | | | | | This changes a debug log to have the same format as the corresponding DESTROY-related log from the forward reactor. Part of #2490
* proto: Pass the cell by reference to resolve a warningGabriela Moldovan2026-05-201-3/+2
|
* proto: Log a message when a forward DESTROY comes alongGabriela Moldovan2026-05-201-3/+15
| | | | Part of #2490
* proto: Wrap PeerInfo in Arc<>Gabriela Moldovan2026-04-232-4/+4
| | | | | | To avoid copying the same information for every circuit, as suggested by @opara in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3399497
* proto: Avoid collecting the chan identities in RelayIdSetGabriela Moldovan2026-04-231-10/+2
| | | | | It doesn't make sense to do so, as pointed out by @opara in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3398956
* proto: Use PeerInfo in the extend handlerGabriela Moldovan2026-04-232-3/+4
| | | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3397922
* proto: Reject EXTEND2 targeting the previous hop in the circuitGabriela Moldovan2026-04-231-1/+13
| | | | | | | The relay reactor will now reject any EXTEND2 that tries to extend the circuit to a hop that shares any identities with our previous hop. Closes #2415
* proto: Give the ExtendRequestHandler a copy of the inbound peer infoGabriela Moldovan2026-04-232-1/+7
| | | | | This will soon be used for preventing the circuit from being extended to the previous hop (#2415).
* proto: Fix broken doc link in extend handlerGabriela Moldovan2026-04-231-1/+3
|
* proto: Extract EXTEND2 handling into a new moduleGabriela Moldovan2026-04-232-200/+254
| | | | | | | | | The EXTEND2 handling logic is fairly self-contained, so I'm moving it outside of the `Forward` handler. This refactoring enables us to add more context to the handler (i.e. the inbound channel identities needed for #2415) without cluttering the `Forward` implementation. I recommend reviewing this commit with `git diff --color-moved`.
* proto: Remove unnecessary clippy allowGabriela Moldovan2026-04-201-2/+0
| | | | | I'm removing this so that we don't accidentally suppress new instances of this warning.
* proto: Use the inbound CircuitAccount when extending circuit (fmt)Gabriela Moldovan2026-03-261-1/+2
|
* proto: Use the inbound CircuitAccount when extending circuitGabriela Moldovan2026-03-261-2/+9
| | | | | This was previously creating a new CircuitAccount in `new_outbound_circ()`, and then immediately dropping it.
* proto: Move handle_unrecognized_cell() out of ForwardHandlerGabriela Moldovan2026-03-251-38/+39
| | | | | | | | | | 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-2/+7
| | | | Closes #2417
* tor-proto: change `dyn ChannelProvider` to also be `Sync`Steven Engler2026-03-241-2/+2
| | | | | An `Arc<T>` is only `Send` if `T` is `Send + Sync`, which is needed by the runtime.
* Fix typosTobias Stoeckmann2026-03-241-1/+1
| | | | Typos found with codespell
* proto: Add more logging to the new circuit reactorsGabriela Moldovan2026-03-121-1/+28
|
* proto: Remove unused function in relay FWD reactorGabriela Moldovan2026-02-121-7/+1
|
* proto: Move decode_relay_cell() out of ForwardHandlerGabriela Moldovan2026-02-121-27/+36
| | | | | | | | 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/+9
| | | | Closes #2339
* proto: Return a protocol error if we get too many RELAY_EARLYGabriela Moldovan2026-02-121-1/+20
|
* proto: Overhaul forward cell handlingGabriela Moldovan2026-02-121-8/+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)
* proto: Give handle_forward_cell() a handle to the hopmgrGabriela Moldovan2026-02-121-1/+5
| | | | | Soon this function will be in charge of decoding the cell too, so it will need a handle to the `HopMgr` (see `decode_relay_cell()`)
* proto: Return internal error on TRUNCATEGabriela Moldovan2026-02-121-1/+1
| | | | | | | | This is not yet implemented, so we should just return an error for now (`todo!()` will cause a panic, shutting down the thread the reactor is running on. We don't want this happening when we start manually testing our WIP impl, because depending on which thread it happens on, it can make the entire relay process unusable).
* proto: Implement validate_backward_cell() for relaysGabriela Moldovan2026-02-111-3/+34
| | | | Closes #2345
* proto: Extend BWD handler with a backward cell handling functionGabriela Moldovan2026-02-111-1/+10
| | | | This will tell the base `BackwardReactor` how to handle the cell.
* proto: Say why it's okay not to have timeouts in a couple of placesGabriela Moldovan2026-02-091-0/+6
|
* proto: Remove the EXTEND2 timeout for nowGabriela Moldovan2026-02-091-26/+11
| | | | | See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3648#note_3339863
* proto: Reject EXTEND2 cells even if we already have an extension in progressGabriela Moldovan2026-02-091-1/+12
|
* proto: Ensure DESTROY gets sent on circuit dropGabriela Moldovan2026-02-051-3/+9
| | | | | | | | | | Implements this part of the spec: ``` To tear down a circuit completely, a relay or client sends a DESTROY cell to the adjacent nodes on that circuit, using the appropriate direction’s circID. ```
* proto: Make handle_extend2() synchronousGabriela Moldovan2026-02-051-3/+2
| | | | | This doesn't need to be async, as it delegates the handling to a background task.
* proto: Implement EXTEND2 handlingGabriela Moldovan2026-02-051-17/+248
| | | | | | | | To handle EXTEND2, the relay `ForwardHandler` impl spawns a background task, which reports back the result via the `CircEvent` MPSC stream. This stream is polled from the `ForwardReactor` main loop, and each `CircEvent` is passed back to `ForwardHandler::handle_event()` for handling.
* proto: Reword an error message for clarityGabriela Moldovan2026-02-051-1/+1
| | | | Users reading the log won't necessarily know what a "forward channel" is.
* proto: Give handle_meta_msg() a handle to the runtimeGabriela Moldovan2026-02-051-1/+2
|
* proto: Add an implementation-dependent reactor event streamGabriela Moldovan2026-02-051-0/+17
| | | | | This will enable us to obtain implementation-dependent asynchronous events (such as the outcome of an extend handshake).
* proto: Make chan_provider an ArcGabriela Moldovan2026-02-051-2/+3
| | | | To match the `ChannelProvider::get_or_launch()` function signature.
* proto: Pass the unique id to Forward handlerGabriela Moldovan2026-02-051-0/+5
| | | | | | We need the unique_id here, because the Forward handler will soon start using the `ChannelProvider::get_or_launch()` to launch outbound channels, which takes the reactor unique_id as an argument.
* proto: Move channel provider out of the generic reactorGabriela Moldovan2026-02-051-2/+16
| | | | | | The channel provider is relay-specific, so I am moving it to the relay `ForwardHandler` implementation. This enables us to get rid of some of the feature gating from the generic reactor.
* proto: Rename chan senders and sinks for clarityGabriela Moldovan2026-01-291-1/+1
| | | | | | | | | | We settled on * `inbound_chan{tx, rx}`, for the inbound channel (the channel towards the guard, if we are a client, or towards the client if we are a relay) * `outbound_chan{tx, rx}`, for the outbound channel (the channel towards the exit, if we are a middle relay)
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:04:51 +0000