summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit
Commit message (Collapse)AuthorAgeFilesLines
* proto: Rename CircSyncView to CircHopSyncView (fmt)Gabriela Moldovan2026-02-161-1/+1
|
* proto: Rename CircSyncView to CircHopSyncViewGabriela Moldovan2026-02-162-16/+7
| | | | 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.
* proto: Replace circuit-scoped n_open_streams() with per-hop alternativeGabriela Moldovan2026-02-161-8/+15
| | | | | | | | | | | | | | | | | `IncomingStreamRequestFilter`s, and `CircSyncView`s, by extension, are used both by old relay implementation and the new one for implementing an out-of-reactor way of deciding how to handle an incoming stream. In the new circuit reactor design, we have a separate stream reactor for each hop. Upon receiving an incoming stream, the stream reactor will need to build one of these `CircSyncView` objects, and then pass it to an externally-provided `IncomingStreamRequestFilter`. Before this change, `CircSyncView::n_open_streams()` returned the total number of open streams, which wouldn't have worked with the new reactor design, because the per-hop stream reactor doesn't have a global view of all the hops, so its `CircSyncView` can't return the total number of streams (at least not without message passing, or sharing state with the other stream reactors).
* proto: Replace CircSyncView with previously client-only CircSyncViewGabriela Moldovan2026-02-161-36/+22
| | | | | | | | | | Note: this commit only contains the removal of the old `CircSyncView`, and it of course doens't compile. A future commit will replace the removed file with the `syncview.rs` from the client module. This change is split over two commits because it makes reviewing easier (`git mv`ing the new file over the old results in a confusing diff, because `git` refuses to show it as a move).
* proto: Rename ClientCircSyncView to CircSyncViewGabriela Moldovan2026-02-161-4/+2
| | | | | This will soon replace `CircSyncView` wholesale. The preliminary renaming will make the future diffs easier to review.
* 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)
* proto: Give handle_forward_cell() a handle to the hopmgrGabriela Moldovan2026-02-121-3/+6
| | | | | 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: Pass *all* cells to handle_forward_cell()Gabriela Moldovan2026-02-121-6/+3
| | | | | | | | | | | | | | | | | Previously, the implementation-dependent `handle_forward_cell()` handled all forward cells *except* for RELAY cells, which were handled in the generic base reactor. This changes the implementation to pass *all* cells, including RELAY cells, to `handle_forward_cell()` too. This is needed because both RELAY and RELAY_EARLY cells need to be handled very similarly: both can be either recognized or unrecognized, with unrecognized cells being handled by the implementation-dependent code, and the recognized ones being sent to the base reactor for handling. A future commit will update `handle_forward_cell()` to extract `Relay` object out of RELAY/RELAY_EARLY cells, and return it back to the base reactor for handling.
* proto: Add big TODO about flushingGabriela Moldovan2026-02-111-0/+13
|
* proto: Start forwarding cells in the backward reactorGabriela Moldovan2026-02-111-4/+11
|
* proto: Extend BWD handler with a backward cell handling functionGabriela Moldovan2026-02-111-0/+16
| | | | This will tell the base `BackwardReactor` how to handle the cell.
* proto: Ensure DESTROY gets sent on circuit dropGabriela Moldovan2026-02-051-0/+11
| | | | | | | | | | 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: Implement EXTEND2 handlingGabriela Moldovan2026-02-051-135/+14
| | | | | | | | 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: Move CREATE helpers to a shared moduleGabriela Moldovan2026-02-051-0/+63
| | | | These will be used by the relay code too (for circuit extension).
* proto: Add BWD command for receiving newly launched outbound channelsGabriela Moldovan2026-02-051-0/+36
|
* proto: Give handle_meta_msg() a handle to the runtimeGabriela Moldovan2026-02-052-2/+8
|
* proto: Add an implementation-dependent reactor event streamGabriela Moldovan2026-02-052-0/+31
| | | | | This will enable us to obtain implementation-dependent asynchronous events (such as the outcome of an extend handshake).
* proto: Move channel provider out of the generic reactorGabriela Moldovan2026-02-052-68/+1
| | | | | | 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: Fix misleading SendRelayMsg docsGabriela Moldovan2026-02-051-1/+1
| | | | This was leftover from back when this command was only for Sendmes.
* proto: Remove assumption that we are a relay from BWD docGabriela Moldovan2026-02-041-1/+1
| | | | This was leftover from back when the BWD was a relay-specific type.
* proto: Replace SendSendme with a more general-purpose command (fmt)Gabriela Moldovan2026-02-041-5/+4
|
* proto: Replace SendSendme with a more general-purpose commandGabriela Moldovan2026-02-043-13/+14
| | | | | This will soon be used for instructing the BWD to send other types of messages too.
* proto: Replace send_sendme() with general-purpose functionGabriela Moldovan2026-02-041-8/+12
| | | | | | | The backward reactor will soon need the ability to send other types of relay messages too: it will soon need the ability to respond to EXTEND2 by sending back an EXTENDED2, so I am preemptively making this function more general so we can reuse it.
* proto: Allow unused async in WIP reactor codeGabriela Moldovan2026-01-291-0/+2
| | | | This will need to become async soon.
* proto: Document that the hop list is shared with the BWDGabriela Moldovan2026-01-291-0/+11
|
* proto: Rename the FWD -> BWD channelGabriela Moldovan2026-01-293-18/+18
| | | | | | | In the backward reactor, we call this the `forward_reactor_rx` (because it receives commands from the foward reactor), and in the forward reactor we call it `backward_reactor_tx` (because it sends commands to the backward reactor).
* proto: Rename chan senders and sinks for clarityGabriela Moldovan2026-01-293-42/+42
| | | | | | | | | | 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)
* proto: Update misleading comment about cmd_rxGabriela Moldovan2026-01-291-1/+1
|
* proto: Allow CircSynvView::new_relay() to be unusedGabriela Moldovan2026-01-291-0/+1
| | | | | This will change significantly in the near future, or disappear entirely.
* proto: Add a new, implementation-agnostic circuit reactorGabriela Moldovan2026-01-297-5/+3063
|
* proto: Avoid locking in CircHopOutbound::ccontrol()Gabriela Moldovan2026-01-291-8/+26
| | | | | | | | This is just because the generic reactor will soon need a clone of the CC object, so I am preemptively making this function return a ref to the underlying `Arc` instead. Technically, it would've been fine to just kept this method and add a separate one returning `&Arc<Mutex<..>>`, but I'd prefer keeping the API small.
* proto: Rip CC state out of CircHopInboundGabriela Moldovan2026-01-291-17/+1
| | | | | | Soon it won't need be needed here any more. I'm removing it, because having redundant handles to the CC state makes it difficult to see exactly where it's being used from.
* proto: Factor ReactorResultChannel into the shared reactor moduleGabriela Moldovan2026-01-291-0/+5
| | | | This is not just for clients!
* proto: Add a new module for the generic circuit reactorGabriela Moldovan2026-01-291-0/+9
| | | | Currently empty, will be fleshed out in a future commit.
* proto: Move padding_disposition() to the shared padding moduleGabriela Moldovan2026-01-291-0/+69
|
* proto: Move CircPaddingDisposition to a new moduleGabriela Moldovan2026-01-291-0/+16
| | | | Relays will need to use it too.
* proto: #[macro_use] be gone!Gabriela Moldovan2025-12-101-0/+2
|
* proto: Move relay specific unit test to relay moduleDavid Goulet2025-12-101-25/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Move unit tests and minor fixDavid Goulet2025-12-101-21/+0
| | | | | | Move the client specific unit tests into the client module. Signed-off-by: David Goulet <[email protected]>
* proto: Move RelayCircChanMsg into relay moduleDavid Goulet2025-12-101-23/+3
| | | | | | This follows the move of the client specific object. Signed-off-by: David Goulet <[email protected]>
* proto: Move ClientCircChanMsg into client moduleDavid Goulet2025-12-101-27/+11
| | | | | | | | Next commit will also move the Relay specific set into the relay module. These two sets are becoming specific to the reactor as the circuit reactor communication channel will use AnyChanMsg instead. Signed-off-by: David Goulet <[email protected]>
* proto: Fix relay/hs-service feature gatingGabriela Moldovan2025-12-081-1/+1
| | | | | Without this, `tor-proto` doesn't compile if you enable the `relay` feature but not `hs-service`.
* Merge branch 'relay-streams2' into 'main'David Goulet2025-12-022-1/+7
|\ | | | | | | | | proto: Start handling incoming streams in the relay reactor See merge request tpo/core/arti!3487
| * proto: Move a couple of stream-related constants to stream mod (fmt)Gabriela Moldovan2025-11-241-1/+1
| |
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 00:29:40 +0000