aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/client/reactor/circuit.rs
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: disable flowctrl sidechannel mitigations for relaysSteven Engler7 days1-1/+13
| | | | | | | | The end result should be: 1. outgoing streams - enable sidechannel mitigations 2. incoming hs streams - enable sidechannel mitigations 3. incoming exit streams - disable sidechannel mitigations
* tor-proto: fix a 'clippy::useless_conversion'Steven Engler2026-08-111-1/+1
|
* proto: Add {backward|forward} prefix to circ_id in logsDavid Goulet2026-08-031-10/+10
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename uniq_id to circ_unique_id mostly in loggingDavid Goulet2026-08-031-10/+10
| | | | | | | | | 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-12/+42
| | | | | | | | | | 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]>
* proto: Remove feature-gating from CircHop::handle_msg()Gabriela Moldovan2026-07-231-1/+3
| | | | | | | | | | | | | | | This feature-gating has been a source of confusion, and it unnecessarily complicates the stream message handling flow. I've previously argued in favour of keeping it, in the spirit of a belt and braces approach to message validation, but I've been convinced that in this particular case, the feature-gate is more trouble than it's worth. What makes things worse is that the `CircHop::handle_msg()` function was designed poorly (by yours truly). I plan on refactoring it at some point, hopefully soon. There is a TODO about this below its doc comment.
* Remove now-unneeded allow(clippy::cognitive_complexity)Jim Newsome2026-07-151-1/+0
|
* proto: Add crate-level exports for two extra stream types (fmt)Gabriela Moldovan2026-06-171-3/+3
|
* tor-proto: have `StreamReqInfo` store a `ReactorStreamComponents`Steven Engler2026-05-211-4/+1
|
* tor-proto: move memquota stream account arg to last positionSteven Engler2026-05-211-3/+3
| | | | This better matches nearby code.
* tor-proto: move more stream queue init to reactorSteven Engler2026-05-211-38/+5
| | | | | | | | | | | | | | | | | | | | Previously when initializing a stream, we constructed most of the stream-related queues outside of the reactor and passed the relevant halves of the queues (senders or receivers) into the reactor. A downside of the above approach is that the reactor may be better informed about what queues to construct, and how to construct them. For example the reactor knows what type of flow control that the hop is using, so it knows whether we need queues for passing rate limits and drain rates for XON/XOFF flow control. This commit moves the construction of these queues into the reactor and passes the relevant halves out of the reactor. In the future we can make better decisions about which queues are needed depending on the flow control method used instead of always constructing them (see arti#2068). Reviewing with `--color-moved` might be helpful as a few lines have been moved.
* tor-proto: add `ReactorStreamComponents` to bundle return valsSteven Engler2026-05-201-5/+4
|
* tor-proto: move stream incoming queue init to reactorSteven Engler2026-05-201-13/+9
| | | | | | | | | | | The stream queue length (for messages incoming from the Tor network) depends on the type of flow control we're using for the hop. Currently we construct the stream queue outside of the circuit reactor, but we don't have the flow control information here. Instead of constructing the stream queue outside of the reactor and passing the sender into the reactor, we construct the stream queue inside of the reactor and pass the receiver out of the reactor.
* tor-proto: clean up return type of `Circuit::begin_stream()`Steven Engler2026-05-111-4/+5
|
* tor-proto: small cleanup of legacy codeSteven Engler2026-04-081-6/+1
| | | | | | | I think it was written like this because earlier versions of rust didn't allow references to temporaries like `&mut rand::rng()` and needed them to be bound to a variable. But this isn't necessary anymore and so the comment doesn't make sense.
* tor-proto: Port to web-time-compatNick Mathewson2026-03-261-1/+1
|
* Fix word duplicate typosTobias Stoeckmann2026-03-151-1/+1
|
* proto: Rename CircSyncView to CircHopSyncViewGabriela Moldovan2026-02-161-3/+3
| | | | And update the docs
* proto: Replace circuit-scoped n_open_streams() with per-hop alternativeGabriela Moldovan2026-02-161-1/+1
| | | | | | | | | | | | | | | | | `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-1/+1
| | | | | | | | | | 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-3/+2
| | | | | This will soon replace `CircSyncView` wholesale. The preliminary renaming will make the future diffs easier to review.
* proto: Move CREATE helpers to a shared moduleGabriela Moldovan2026-02-051-2/+1
| | | | These will be used by the relay code too (for circuit extension).
* proto: Move padding_disposition() to the shared padding moduleGabriela Moldovan2026-01-291-54/+5
|
* proto: Move CircPaddingDisposition to a new moduleGabriela Moldovan2026-01-291-13/+1
| | | | Relays will need to use it too.
* proto: Move TimeoutEstimator to utilGabriela Moldovan2026-01-291-2/+2
| | | | | This will be used in the stream reactor too (and the stream reactor will eventually replace the corresponding client impl).
* proto: Dedupe IncomingStreamRequestHandlerGabriela Moldovan2026-01-121-3/+9
|
* proto: Client circuit reactor now handles AnyChanMsgDavid Goulet2025-12-101-2/+2
| | | | | | | | | | | | | | | 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 ClientCircChanMsg into client moduleDavid Goulet2025-12-101-2/+2
| | | | | | | | 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]>
* Merge branch 'relay-streams2' into 'main'David Goulet2025-12-021-31/+5
|\ | | | | | | | | proto: Start handling incoming streams in the relay reactor See merge request tpo/core/arti!3487
| * proto: Appropriately gate STREAM_READER_BUFFER to satisfy clippyGabriela Moldovan2025-11-241-1/+4
| |
| * proto: Deduplicate msg_streamid()Gabriela Moldovan2025-11-241-19/+1
| | | | | | | | | | | | | | | | | | | | Initially I wanted to turn `msg_streamid()` into a method on `UnparsedRelayMsg`, but I ultimately decided against it, because it feels like it doesn't belong there (even though intuitively, I would've expected it to handle the mismatch between stream ID and cell command internally). This is because all the `UnparsedRelayMsg` methods return `tor_bytes::Result`, and do not actually do any validation beyond some length checks on the various fields.
| * proto: Move a couple of stream-related constants to stream modGabriela Moldovan2025-11-241-12/+1
| |
| * proto: Make the hop in StreamReqInfo optionalGabriela Moldovan2025-11-241-1/+1
| | | | | | | | We are about to use `StreamReqInfo` for exit streams too.
* | opentelemetry: Instrument a bunch of functions.Wesley Aptekar-Cassels2025-11-241-1/+6
|/ | | | | These are all aimed at figuring out in more detail what's going on in #2079 and related issues.
* proto: Make cc state shared between CircHop{Inbound,Outbound}Gabriela Moldovan2025-11-171-4/+4
| | | | | | | | | | | | | The relay reactor needs the cc state to be shared between the inbound and outbound components (i.e. the forward and backward reactors), so we need to put the cc state behind a mutex. There will never be any contention on this mutex in the client impl, because the client reactor doesn't split the `CircHop` into `CircHopInbound` and `CircHopOutbound`. In the future, we should work on trying to reduce the number of locks in the `CircHop` states.
* proto: Make the hop in SendRelayCell optionalGabriela Moldovan2025-11-171-6/+7
|
* proto: Remove duplicated function in CircHopGabriela Moldovan2025-11-131-2/+2
| | | | | `CircHop::relay_format()` returned the same thing as `CircHop::relay_cell_format()`.
* Merge branch 'cell-sender' into 'main'Alexander Hansen Færøy2025-11-101-2/+1
|\ | | | | | | | | proto: Move cell_sender out of the client module See merge request tpo/core/arti!3407
| * proto: Move cell_sender out of the client moduleGabriela Moldovan2025-10-281-2/+1
| | | | | | | | | | | | | | Soon we'll use CircuitCellSender in the relay reactor too (we need to, because it provides a useful abstraction for handling block/unblock padding actions, and because it has some handy helper functions such as `congestion_signals()`).
* | proto: Replace ClientCircSyncView in IncomingStreamRequestFilterGabriela Moldovan2025-10-301-1/+2
|/
* proto: Move StreamMpsc{Sender,Receiver} to stream module (fmt)Gabriela Moldovan2025-10-211-1/+1
|
* proto: Move StreamMpsc{Sender,Receiver} to stream moduleGabriela Moldovan2025-10-211-1/+2
| | | | These will be shared with the relay code.
* proto: Move hop settings into a shared moduleGabriela Moldovan2025-10-211-3/+4
|
* 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: Move dumb pipes to top-lvl stream module (fmt)Gabriela Moldovan2025-10-211-1/+1
|
* proto: Move dumb pipes to top-lvl stream moduleGabriela Moldovan2025-10-211-1/+1
|
* Refactor: turn circ_extensions_from_settings into a methodNick Mathewson2025-10-201-61/+1
| | | | Closes #2067.
* proto: Rename data cmd checkers to {Inbound,Outbound}DataCmdCheckerGabriela Moldovan2025-10-161-2/+2
| | | | | | The previous "incoming" terminology was rather ambiguous. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 22:22:25 +0000