aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay
Commit message (Collapse)AuthorAgeFilesLines
...
* proto: Pass all the padding-related objects to the relay reactorsGabriela Moldovan2025-11-243-2/+24
| | | | 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: Add an IncomingStreamConfig to pass to the reactorGabriela Moldovan2025-11-241-2/+12
|
* proto: Rework relay reactor error handlingGabriela Moldovan2025-11-241-8/+15
| | | | | | | I've made `run()` more similar to its client circuit reactor counterpart (I think the error reporting will be better, and if we ever need to make the reactor public, it will be easier this way because now `run()` doesn't expose the crate-private `ReactorError` type).
* proto: Rename RelayReactor to ReactorGabriela Moldovan2025-11-243-12/+12
| | | | | This is already namespaced under the `relay` module so the `Relay` prefix is redundant.
* proto: Give RelayCirc a DynTimeProviderGabriela Moldovan2025-11-241-1/+2
| | | | This will be needed soon.
* proto: Make the forward -> backward reactor chan boundedGabriela Moldovan2025-11-243-5/+12
| | | | | | | 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-242-21/+46
| | | | | 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-242-3/+17
| | | | | 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: Return early if the cell is unrecognizedGabriela Moldovan2025-11-241-11/+11
| | | | | | Rewriting the code this way reduces the indentation level for the "recognized cell" case (which is not yet implemented, but will be very soon), thereby making it more readable.
* proto: Move comment in relay handshake.rsDavid Goulet2025-11-191-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Implement part of UnverifiedRelayChannel::finish()David Goulet2025-11-191-10/+37
| | | | | | | | | | The UnverifiedChannel::finish() was split in previous commit so this adds the support for sending the right NETINFO cell instead of the client specific one. Added more TODOs for followup commits. Signed-off-by: David Goulet <[email protected]>
* proto: Add VerifiedRelayChannel implementationDavid Goulet2025-11-191-1/+31
| | | | | | | | Add the finish() function that for now simply calls the generic finish(). There is a bunch of TODO in the code in this commit explaining why we haven't made the implementation relay specific just yet. Signed-off-by: David Goulet <[email protected]>
* proto: Add UnverifiedRelayChannel implementationDavid Goulet2025-11-192-17/+100
| | | | | | | | | | | | | | This commits takes out the relay specific code out of UnverifiedChannel and puts it in UnverifiedRelayChannel. In order to pull this off, we added some fiels to the VerifiedChannel struct so the relay code get back generated data from the UnverifiedChannel::check() in order to do its validation work and yield a VerifiedRelayChannel. This also lead to a cleanup of expect() and ChannelType::is_initiator(). Signed-off-by: David Goulet <[email protected]>
* proto: Introduce relay specific channel structsDavid Goulet2025-11-191-2/+38
| | | | | | | | | | The new UnverifiedRelayChannel and VerifiedRelayChannel struct are added to decouple the client code and put the relay component in its module. Both objects hold the to become generic object that both client and relay will use to create a channel. Signed-off-by: David Goulet <[email protected]>
* proto: Use CircHopInbound in the ForwardReactor (fmt)Gabriela Moldovan2025-11-173-6/+4
|
* proto: Use CircHopInbound in the ForwardReactorGabriela Moldovan2025-11-172-19/+15
|
* proto: Use CircHopOutbound in BackwardReactorGabriela Moldovan2025-11-172-34/+24
|
* 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: Remove redundant channel from RelayCircGabriela Moldovan2025-10-291-1/+0
| | | | | We don't really need this channel here, because we already have control and command channels for checking if the reactor task is still alive.
* proto: Rename RelayReatorHandle to RelayCircGabriela Moldovan2025-10-291-3/+3
| | | | | | | | | While this is technically a "reactor handle", I think RelayCirc sounds better, because this is essentially our only public API for interacting with a relay circuit (it will be used outside of tor-proto). (This would also be consistent with our existing ClientCirc client-side terminology).
* proto: Move RelayReactorHandle to relay moduleGabriela Moldovan2025-10-291-11/+1
| | | | This will soon become `pub`, so I am factoring it out of `reactor.rs`.
* proto: Update RelayReactorHandle docsGabriela Moldovan2025-10-291-1/+1
| | | | | | | | BackwardReactor is an implementation detail, so it shouldn't really be mentioned in the soon-to-be-public-facing docs. And besides, the control messages are no longer handled by the BackwardReactor.
* proto: Avoid identifying relay circuits using TunnelIdGabriela Moldovan2025-10-271-3/+3
| | | | We replaced TunnelId with UniqId in the relay code a while ago.
* proto: Remove relay ChannelAuthenticationData builderDavid Goulet2025-10-231-64/+11
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Use Arc for relay identities objectDavid Goulet2025-10-232-4/+6
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Remove LOG_PREFIX in relay handshakeDavid Goulet2025-10-231-5/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Compute authenticate data after validating certificatesDavid Goulet2025-10-232-9/+8
| | | | | | | | | | | | | | This is only done if we kept the AUTH_CHALLENGE cell and we have relay identities. In other words, this is only when the UnverifiedChannel was created from a RelayInitiatorHandshake. Note: The check_internal() function is too large and should be refactored in smaller pieces. Note: It is also likely that we need to split UnverifiedChannel and VerifiedChannel as it is getting client or relay members. Not great. Signed-off-by: David Goulet <[email protected]>
* proto: Add a relay channel builderDavid Goulet2025-10-232-1/+36
| | | | | | | | | | The client and relay channel builder don't share anything and return different objects hence the seperation. Furthermore, this seperation avoids having the client ChanMgr ability to launch relay channels. Signed-off-by: David Goulet <[email protected]>
* proto: Add RelayIdentities object holding our keysDavid Goulet2025-10-232-1/+61
| | | | | | | | | | | | | | | This is a intermediary object between tor-chanmgr and tor-proto that is when building a relay channel, those keys/certs need to be set in the ChannelBuilder so the tor-proto can use them to authenticate. We avoid that way making tor-proto depending on tor-keymgr for the ultimate goal to avoid tor-proto to have access to all the keys in the KeyMgr. Future commits will introduce a relay channel builder which will use that object to set the keys. Signed-off-by: David Goulet <[email protected]>
* proto: Add the channel authentication dataDavid Goulet2025-10-231-2/+147
| | | | | | | | | | | This commit only adds a struct holding all the authentication data that needs to be built during the verification process after all handshake cells needed for authentication have been sent. It lives in the VerifiedChannel struct so it can be used to build the AUTHENTICATE cell and be sent before the NETINFO. Signed-off-by: David Goulet <[email protected]>
* proto: Add RelayInitiatorHandshakeDavid Goulet2025-10-232-0/+132
| | | | | | | This implements the relay initiator side of the handshake up to the creation of an unverified channel. Signed-off-by: David Goulet <[email protected]>
* proto: Replace select! with select_biased!Gabriela Moldovan2025-10-221-2/+2
| | | | We need to give the control channels higher priority here.
* proto: Update an outdated doc linkGabriela Moldovan2025-10-221-1/+1
|
* proto: Add debug log when RelayReactor shuts downGabriela Moldovan2025-10-221-2/+14
|
* proto: Replace futures::select with importGabriela Moldovan2025-10-221-2/+2
|
* proto: Remove no-longer relevant note on control message handlingGabriela Moldovan2025-10-221-10/+0
|
* proto: Remove an already-addressed TODOGabriela Moldovan2025-10-221-2/+0
|
* proto: Handle control messages in RelayReactorGabriela Moldovan2025-10-222-51/+53
| | | | Control messages are handled in RelayReactor instead of BackwardReactor.
* proto: Move the control channels to RelayReactorGabriela Moldovan2025-10-222-53/+53
| | | | | 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: Prioritize shutdown over everything elseGabriela Moldovan2025-10-211-8/+8
|
* proto: Ensure RelayReactor shuts down the other reactorsGabriela Moldovan2025-10-213-21/+48
| | | | | | | | | 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 TODO about moving control message handling to RelayReactorGabriela Moldovan2025-10-211-0/+3
|
* proto: Use select not joinGabriela Moldovan2025-10-211-4/+5
| | | | | I used `futures::join` by mistake: the intention here is to have `RelayReactor` exit when either one of the fwd/bwd reactors exits.
* proto: Emphasize that we think 2 reactors are better for perfGabriela Moldovan2025-10-211-4/+8
|
* proto: Add a TODO about splitting out fields out of BackwardReactorGabriela Moldovan2025-10-211-0/+9
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 07:29:17 +0000