aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay/reactor/backward.rs
Commit message (Collapse)AuthorAgeFilesLines
* proto: Add {backward|forward} prefix to circ_id in logsDavid Goulet2026-08-031-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename uniq_id to circ_unique_id mostly in loggingDavid Goulet2026-08-031-2/+2
| | | | | | | | | 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-031-2/+4
| | | | | | | | | | 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]>
* proto: Remove TODOs about flushing pending dataGabriela Moldovan2026-05-261-4/+0
| | | | | | We decided the reactor is the wrong place to handle this. See discussion in #2490
* 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: 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: Replace relay reactor with new generic reactorGabriela Moldovan2026-01-291-845/+36
|
* proto: Avoid locking in CircHopOutbound::ccontrol()Gabriela Moldovan2026-01-291-1/+8
| | | | | | | | 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: Dedupe IncomingStreamRequestHandlerGabriela Moldovan2026-01-121-29/+4
|
* proto: Give IncomingStreamRequestHandler a HopNumGabriela Moldovan2026-01-121-1/+5
| | | | | | | | This currently duplicates the client `IncomingStreamRequestHandler`. To deduplicate it, we need the `hop_num` to be optional (it will be `None` for relays, and `Some(hopnum)` in the client reactor). The next commit will fix the code duplication.
* proto: Rename Circuit{Action/Event}::Shutdown to ProtoViolationDavid Goulet2025-12-101-5/+5
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Relay circuit reactor now handles AnyChanMsgDavid Goulet2025-12-101-1/+10
| | | | | | | Same as the client reactor, a message outside of our restricted set leads to a reactor shutdown. Signed-off-by: David Goulet <[email protected]>
* proto: Client circuit reactor now handles AnyChanMsgDavid Goulet2025-12-101-1/+1
| | | | | | | | | | | | | | | This commit removes the CircuitRx* based solely on the client circuit message and moves it into the top level of the crate so all reactors can use them. The client reactor then upon receiving the message, it converts the AnyChanMsg into a ClientCircChanMsg. On error, this leads to a shutdown of the entire reactor due to a fatal error. In order to pull this off, we added a CircuitAction::Shutdown that is handled as a priority. Signed-off-by: David Goulet <[email protected]>
* proto: Move RelayCircChanMsg into relay moduleDavid Goulet2025-12-101-1/+1
| | | | | | This follows the move of the client specific object. Signed-off-by: David Goulet <[email protected]>
* proto: Explain why we have the backward sink readiness checkGabriela Moldovan2025-12-021-4/+26
|
* proto: Resolve some clippy warnings, remove allowsGabriela Moldovan2025-11-241-3/+1
|
* proto: Reword a nonsensical TODOGabriela Moldovan2025-11-241-3/+15
| | | | | | This TODO was copied over from the client reactor, but it doesn't make any sense here (we don't yet handle control messages in the backward reactor).
* proto: Fix a number of newly broken doc linksGabriela Moldovan2025-11-241-1/+1
|
* proto: Start handling incoming stream requestsGabriela Moldovan2025-11-241-8/+355
| | | | | | | | | | | | | | | | | | | | | | | | | | | The relay reactor is now able to handle incoming stream requests (i.e. cells that open streams). It currently only supports DATA stream requests (BEGIN); support for other stream types (BEGIN_DIR, RESOLVE) will be added later. `Reactor::new()` now returns the futures::Stream of Tor streams, alongside the `Reactor` and `RelayCirc` handle. Whoever calls `Reactor::new()` is responsible for passing the stream of streams over to the task that is meant to handle it ("handle" in this case means either rejecting the stream with a given `END` cell, or accepting it and forwarding the connection between it and the corresponding application stream). IMPORTANT: the above is a bit half-baked! Next on my TODO list is is to iron out the details of how/where this will actually be handled. I am also a bit unsure about the API here: I think it might've been nicer to give the user the ability to obtain this `futures::Stream` from `RelayCirc`, which is, after all, a handle to the reactor? Also on my short-term TODO list is to figure out how conflux will affect this API and usage. And there is another wrinkle here: for incoming DATA stream requests, the handler will need to produce a resulting `DataStream`, which is not yet fully implementation-agnostic (it wraps a `ClientDataStreamCtrl`). This too will be handled in a separate MR.
* proto: Pass all the padding-related objects to the relay reactorsGabriela Moldovan2025-11-241-1/+11
| | | | These will need to be handled soon
* proto: Make send_msg_to_client() take an AnyRelayMsgOuterGabriela Moldovan2025-11-241-4/+5
| | | | | This is needed because we will soon have another callsite for it, which will need to pass `AnyRelayMsgOuter`.
* proto: Rename RelayReactor to ReactorGabriela Moldovan2025-11-241-4/+4
| | | | | This is already namespaced under the `relay` module so the `Relay` prefix is redundant.
* proto: Make the forward -> backward reactor chan boundedGabriela Moldovan2025-11-241-2/+2
| | | | | | | This MPSC channel now has zero buffering, because if the backward reactor can't send the cell, the forward reactor must immediately stop reading from its inputs (note that the backward reactor's Tor channel towards the client *does* have a buffering layer).
* proto: Let cell_rx carry more than just stream dataGabriela Moldovan2025-11-241-15/+32
| | | | | There are other types of messages (like circuit-level SENDMEs) that need to be handled in the backward reactor too.
* proto: Give RelayReactor and BackwardReactor a RuntimeGabriela Moldovan2025-11-241-1/+6
| | | | | We will soon need a handle to the runtime in BackwardReactor (we need a time provider to call `note_sendme_received()`).
* proto: Don't poll PollAll unless we can write to chanGabriela Moldovan2025-11-241-14/+9
| | | | | We need to avoid reading from all of these if the chan_sender isn't ready, because otherwise we can't provide backpressure.
* proto: Use CircuitCellSender in the backward reactorGabriela Moldovan2025-11-241-8/+14
| | | | | | | | | | | | The backward reactor needs this for handling padding (because it may need to e.g. put the chan sender in a blocked state). Note that `CircuitCellSender` has an underlying `SometimesUnboundedSink`, so from now on we must be very careful and avoid writing to the `chan_sender` if it's not ready (because otherwise we can end up buffering unboundedly). The next commit will add some extra checks against reading from futures::Streams that might cause us to write to the `chan_sender` sink (futures::Sink).
* proto: Use CircHopInbound in the ForwardReactor (fmt)Gabriela Moldovan2025-11-171-1/+1
|
* proto: Use CircHopOutbound in BackwardReactorGabriela Moldovan2025-11-171-31/+15
|
* proto: Move SendRelayCell to circhop (fmt)Gabriela Moldovan2025-11-171-1/+1
|
* proto: Move CloseStreamBehavior to top-level stream moduleGabriela Moldovan2025-11-141-1/+2
|
* proto: Handle control messages in RelayReactorGabriela Moldovan2025-10-221-28/+0
| | | | Control messages are handled in RelayReactor instead of BackwardReactor.
* proto: Move the control channels to RelayReactorGabriela Moldovan2025-10-221-49/+6
| | | | | This only moves the control/command fields to RelayReactor. The next step is to actually implement the control message handling and dispatch.
* proto: Fix broken doc linksGabriela Moldovan2025-10-211-2/+3
|
* proto: Ensure RelayReactor shuts down the other reactorsGabriela Moldovan2025-10-211-12/+21
| | | | | | | | | The `RelayReactor` now holds the sending end of the shutdown broadcast channel, so if `RelayReactor` exits, both the forward and the backward relay reactor will notice and shut down too. Similarly, if the forward or backward reactor exits, the `RelayReactor` will notice (because it select!s between the two), and will shut down
* proto: Add a TODO about splitting out fields out of BackwardReactorGabriela Moldovan2025-10-211-0/+9
|
* proto: Move channel provider to ForwardReactorGabriela Moldovan2025-10-211-12/+3
| | | | | | | | The channel provider is used to request outgoing channels from the `ChanMgr` in response to `EXTEND`/`EXTEND2` cells, so it belongs in the `ForwardReactor`. (This was leftover from the old circ reactor architecture)
* proto: Remove no longer needed MutexGabriela Moldovan2025-10-211-7/+5
|
* proto: Remove stray words from docsGabriela Moldovan2025-10-211-1/+1
|
* proto: Disambiguate "channel" and "stream"Gabriela Moldovan2025-10-211-35/+35
|
* proto: Fix docs post-renamingGabriela Moldovan2025-10-211-3/+3
|
* proto: Replace select_biased! with PollAllGabriela Moldovan2025-10-211-32/+124
| | | | | This is the first step towards parallelizing stream reads and writes.
* proto: Replace placeholder () with stream id and msgGabriela Moldovan2025-10-211-3/+2
| | | | | This makes it a bit clearer that `cell_rx` is for moving stream data between `ForwardReactor` and `BackwardReactor`.
* proto: Replace inbound/outbound terminologyGabriela Moldovan2025-10-211-13/+13
| | | | The forward/backward terminology is clearer.
* proto: Restrict the visibility of BackwardReactorGabriela Moldovan2025-10-211-3/+3
| | | | | BackwardReactor is not meant to be used directly (the channel reactor is supposed to use the `RelayReactor` wrapper instead).
* proto: Move BackwardReactor to its own moduleGabriela Moldovan2025-10-211-0/+450
`BackwardReactor` now exists alongside `ForwardReactor`, to make it clearer that they are siblings.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:14:47 +0000