aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/client/reactor/conflux.rs
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: change some instances of `sendme_inc` to u8Steven Engler2026-08-121-1/+1
|
* proto: Add {backward|forward} prefix to circ_id in logsDavid Goulet2026-08-031-3/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename uniq_id to circ_unique_id mostly in loggingDavid Goulet2026-08-031-8/+8
| | | | | | | | | 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-3/+10
| | | | | | | | | | 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-5/+5
| | | | | | | | | | | | | | | 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: Simplify a match+if statement.Nick Mathewson2026-04-211-13/+5
|
* Fix word duplicate typosTobias Stoeckmann2026-03-151-1/+1
|
* proto: Rename CircuitAction and cie to CircuitEventDavid Goulet2025-12-101-30/+30
| | | | | | | | | | This mirrors also the relay reactor. We've introduced the ProtoViolation into a previous commit which is not an action but rather an "event" that happened on a circuit. And so, better semantic. No behavior change. Signed-off-by: David Goulet <[email protected]>
* proto: Rename Circuit{Action/Event}::Shutdown to ProtoViolationDavid Goulet2025-12-101-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add TODO in client reactor for bad cellDavid Goulet2025-12-101-0/+6
| | | | | | Because of https://gitlab.torproject.org/tpo/core/torspec/-/issues/385 Signed-off-by: David Goulet <[email protected]>
* proto: Client circuit reactor now handles AnyChanMsgDavid Goulet2025-12-101-3/+8
| | | | | | | | | | | | | | | 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: Allow unstable_name_collisions in several placesGabriela Moldovan2025-12-011-0/+5
|
* opentelemetry: Instrument a bunch of functions.Wesley Aptekar-Cassels2025-11-241-1/+4
| | | | | These are all aimed at figuring out in more detail what's going on in #2079 and related issues.
* proto: Make the hop in SendRelayCell optionalGabriela Moldovan2025-11-171-2/+3
|
* proto: Move SendRelayCell to circhopGabriela Moldovan2025-11-171-1/+2
| | | | | This will be used by relays too, once we modify it to make the `HopNum` optional.
* tor-proto: Track information on when tunnels were last usedNick Mathewson2025-11-121-0/+9
| | | | This is part of an implementation for proposal 368.
* proto: Move streammap out of the client module (fmt)Gabriela Moldovan2025-10-211-1/+1
|
* proto: Move streammap out of the client moduleGabriela Moldovan2025-10-211-1/+1
|
* proto: Replace magic value with constant (fmt).Gabriela Moldovan2025-09-251-1/+2
|
* proto: Replace magic value with constant.Gabriela Moldovan2025-09-251-4/+9
| | | | | Also derives `CIRC_ACTION_COUNT` from the two other constants instead of hard-coding the value.
* proto: Use MAX_CONFLUX_LEGS instead of magic number.Gabriela Moldovan2025-09-251-1/+2
| | | | | Besides, it's better if we use the same number for the expected number of legs as we do in the conflux set impl.
* proto: Make padding and timeout actions take priority.Gabriela Moldovan2025-09-251-34/+69
| | | | | | | | | | This rewrites `next_circ_action()` yet again, using two layers of `PollAll`: * the inner layer drives an individual circuit leg. Each circuit has a `PollAll` that drives its futures * the outer layer drives the inner `PollAll`s belonging to the circuits that form the tunnel
* proto: Add comment emphasizing that the PollAll ordering matters.Gabriela Moldovan2025-09-251-0/+7
|
* proto: Add comment explaining why we need the chan_sender readiness check.Gabriela Moldovan2025-09-251-0/+3
|
* proto: Rewrite should_skip_join_point to return bool.Gabriela Moldovan2025-09-251-11/+10
| | | | | We don't really need to return a `HopNum` anymore (because we work out the join point `HopNum` unconditionally in `next_circ_action`).
* proto: Avoid polling join point streams more than once.Gabriela Moldovan2025-09-251-6/+11
| | | | | | If we poll the ready streams on the join point more than once per reactor loop, we risk sending more than one DATA cell (which is not good, because cc might block after the first cell is sent).
* proto: Rewrite ConfluxSet::next_circ_action() using PollAll.Gabriela Moldovan2025-09-251-125/+102
| | | | | | | | | | | | | | | | | This removes our usage of `FuturesUnordered` in `ConfluxSet::next_circ_action()` to address two issues: * a fairness issue, where the futures driven by `FuturesUnordered` could be starved under some circumstances (#2180) * a logic error, where we'd explicitly avoid reading from the input channel if the outgoing `chan_sender` channel was blocked (#2179) Note that the fixing the latter will cause the reactor to buffer more into the unbounded `chan_sender` sink, but that *should* be okay, because no input message should be able cause us to queue cells excessively. Closes #2179, #2180
* proto: Return multiple actions from next_circ_action.Gabriela Moldovan2025-09-251-2/+12
| | | | | | | Part of #2180 Note: the code is intentionaly left misindented to make reviewing a bit easier. A future commit will fix the indentation.
* proto: Push conflux state checks inside handshake_timeout() (fmt).Gabriela Moldovan2025-09-251-6/+6
|
* proto: Push conflux state checks inside handshake_timeout().Gabriela Moldovan2025-09-251-6/+2
| | | | | | This simplifies the calling code, which will, in turn, make it easier for us to simplify the logic in ConfluxSet::next_circ_action() and abolish the questionable use of FuturesUnordered.
* proto: Remove half-streams when they expire.Gabriela Moldovan2025-09-161-1/+10
| | | | Closes #264
* proto: Implement run_padding_action.Nick Mathewson2025-09-091-5/+20
|
* proto: Watch for PaddingEvents in tunnel reactor.Nick Mathewson2025-09-091-0/+22
| | | | | | | Here we give every Circuit in a conflux set its own PaddingEventStream, and poll it as appropriate. We don't yet actually implement the "take an action" code.
* proto: Apply deferred fmt.Gabriela Moldovan2025-09-041-1/+1
|
* proto: Group the conflux imports.Gabriela Moldovan2025-09-041-6/+2
|
* proto: Use ConfluxCmd instead of CircuitCmd.Gabriela Moldovan2025-09-041-1/+2
| | | | | | This enables us to make the conflux handler logic implementation-agnostic (we want to avoid using `CircuitCmd` here, because it is specific to client circuits).
* proto: Move abstract conflux handlers outside of the client module.Gabriela Moldovan2025-09-041-6/+5
| | | | | | | | | | This moves the shared types under `tor_proto::conflux`. Note: the shared types currently import `CircuitCmd` from `client`. A future commit will change the signature of `handle_msg` to return something other than `CircuitCmd` (this will also improve readability, because in reality, that function can never return most `CircuitCmd` variants).
* proto: Move cmd_counts_towards_seqno to a new conflux module.Gabriela Moldovan2025-09-041-53/+5
| | | | | | | `tor_proto::conflux` is where the shared conflux logic will live. Soon the generic parts of the conflux handlers will be moved there (whereas the client-specific `AbstractConfluxMsgHandler` impl will continue living under `tor_proto::client`).
* proto: Make the ConfluxMsgHandler constructor take an abstract handler.Gabriela Moldovan2025-09-041-2/+5
| | | | | | This will enable us to pull `ConfluxMsgHandler` outside of the `client` module (this is needed because relays are meant to use this type as well, but with a different `AbstractMsgHandler`)
* proto: Pass the cwnd params to the conflux message handler.Gabriela Moldovan2025-09-041-0/+30
| | | | | | These will be used for validating SWITCH cells. Part of #2031
* proto: Move TunnelId to a separate, shared module (fmt).Gabriela Moldovan2025-08-281-1/+1
|
* proto: Move TunnelId to a separate, shared module.Gabriela Moldovan2025-08-281-1/+2
| | | | | | | | | | | | | The `TunnelId*` types will be reused in the relay reactor (exit relays need to have the concept of a "tunnel ID" because of conflux). Now the `relay::reactor` module only has a single import from `client` (for the `unwrap_or_shutdown` helper, which we should be able to remove soon). From now, we will avoid importing anything from `client` in the `relay` module, and instead prefer refactoring the code as needed (to pull the implementation-agnostic parts outside of `client`). This commit has no functional changes, just code motion.
* proto: Add a circuit module shared between client and relay impls.Gabriela Moldovan2025-08-281-2/+3
| | | | | | | This is just code motion (I suggest reviewing with `--color-moved`). This also moves the implementation-agnostic parts from `tor_proto::client::circuit` to a new `tor_proto::circuit` module.
* proto: Rename the `tunnel` module to `client` (fmt).Gabriela Moldovan2025-08-181-1/+1
|
* proto: Rename the `tunnel` module to `client`.Gabriela Moldovan2025-08-181-0/+1199
The implementation from `tunnel` is client-specific, so we are renaming the module accordingly. The more generic parts will be pulled into a separate module in a future commit.