summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: have `StreamReqInfo` store a `ReactorStreamComponents`Steven Engler2026-05-212-5/+13
|
* tor-proto: move memquota stream account arg to last positionSteven Engler2026-05-212-3/+3
| | | | This better matches nearby code.
* tor-proto: clean up `CIRCUIT_BUFFER_SIZE`Steven Engler2026-05-212-8/+1
|
* tor-proto: move more stream queue init to reactorSteven Engler2026-05-212-47/+73
| | | | | | | | | | | | | | | | | | | | 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-202-6/+23
|
* tor-proto: always use a bounded mpsc queue for streamsSteven Engler2026-05-201-13/+7
| | | | | | | | | | | | Whether a stream queue should be bounded or unbounded is a decision that needs to be made at runtime depending on the type of flow control used, not at build-time. Window-based flow control should be bounded and XON/XOFF flow control should be unbounded. If we wanted to support both bounded and unbounded queues, it would take a bunch of boilerplate code to wrap the senders and receivers in enums. Instead we make the queue always bounded, but use a large bound for XON/XOFF flow control.
* tor-proto: move stream incoming queue init to reactorSteven Engler2026-05-202-24/+33
| | | | | | | | | | | 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: small cleanup of `CircHopOutbound::build_flow_ctrl()`Steven Engler2026-05-201-11/+4
|
* tor-proto: fix flow control for half-streamsSteven Engler2026-05-071-3/+0
| | | | | | | | | | This moves the window-based flow control for half-streams out of the `HalfStream` and into the `HalfStreamWindowFlowCtrl` object. Now that it's applied only in `HalfStreamWindowFlowCtrl` and not generally for all half-streams, we no longer apply window-based flow control to half-streams when they're really using xon/xoff-based flow control.
* Merge branch 'stream-close' into 'main'opara2026-04-201-6/+9
|\ | | | | | | | | tor-proto: Small comment and variable name changes See merge request tpo/core/arti!3865
| * tor-proto: small comment and variable name changesSteven Engler2026-04-071-6/+9
| | | | | | | | I think this makes the code a little easier to follow.
* | Merge branch 'create-fast' into 'main'opara2026-04-081-0/+19
|\ \ | |/ |/| | | | | Add support for handling CREATE_FAST cells and launching a circuit reactor See merge request tpo/core/arti!3846
| * Revert "tor-proto: change `CreateResponse` to `restricted_msg!`"Steven Engler2026-04-081-16/+18
| | | | | | | | This reverts commit 9c38daf2d3548feca2ff555f5bd52165add0d20c.
| * tor-proto: add a `From<$ttype>` impl for `RestrictedChanMsgSet`Steven Engler2026-04-081-0/+8
| | | | | | | | This is needed for the revert in the following commit.
| * tor-proto: add a `CreateRequest` restricted msg setSteven Engler2026-04-081-1/+11
| |
| * tor-proto: change `CreateResponse` to `restricted_msg!`Steven Engler2026-04-081-17/+16
| | | | | | | | | | This better fits with existing code that uses `restricted_msg!` and is a bit more flexible.
* | tor-proto: allow sending DATA cells on closed streamsSteven Engler2026-03-291-6/+12
|/ | | | | Previously we would close the circuit, which isn't great because there can be other streams in use on the circuit.
* tor-proto: Port to web-time-compatNick Mathewson2026-03-261-1/+1
|
* proto: Update reactor docs to reflect ForwardHandler changeGabriela Moldovan2026-03-251-6/+37
|
* proto: Move handle_unrecognized_cell() out of ForwardHandlerGabriela Moldovan2026-03-251-12/+1
| | | | | | | | | | The `ForwardHandler` trait is meant for implementation-dependent functions that are called from the implementation-agnostic `ForwardReactor`. Previously `handle_unrecognized_cell()` was called directly by the generic `ForwardReactor`, but that's no longer the case, so it doesn't belong in the trait anymore. This commit is just code motion. Best reviewed with `--color-moved`
* proto: Forward unrecognized RELAY_EARLY as RELAY_EARLYGabriela Moldovan2026-03-251-0/+1
| | | | Closes #2417
* proto: Use AllowAllStreamsFilter in relay builds tooGabriela Moldovan2026-03-251-2/+2
|
* proto: Move AllowAllStreamsFilter to crate-pub test moduleGabriela Moldovan2026-03-251-0/+16
| | | | This will soon be used by the relay tests too.
* proto: Add option to create RELAY_EARLY via rmsg_to_ccmsg() (fmt)Gabriela Moldovan2026-03-251-1/+5
|
* proto: Add option to create RELAY_EARLY via rmsg_to_ccmsg()Gabriela Moldovan2026-03-251-2/+8
| | | | This will be needed for the relay circuit reactor tests.
* proto: Move rmsg_to_ccmsg to crate-pub test moduleGabriela Moldovan2026-03-251-0/+33
| | | | We'll soon need this for the relay reactor tests too.
* Fix typosTobias Stoeckmann2026-03-242-2/+2
| | | | Typos found with codespell
* proto: Replace TimeoutEstimator with opaque handlerGabriela Moldovan2026-03-192-49/+12
| | | | | | | | | | | | | | | This replaces the client-specific half-stream expiry calculation from the stream reactor (which is meant to be implementation agnostic) with a call to the new `StreamHandler::halfstream_expiry()`, which abstracts away the implementation-specific half-stream expiry calculation (for example, on the client-side, the calculation takes into account the CBT, which we don't have on the relay side). Note that there is currently no `StreamHandler` implementation on the client-side (because we haven't ported the client circuit reactor to the new reactor yet). Closes #2410
* proto: Add a trait for customizing StreamReactor behaviorGabriela Moldovan2026-03-191-0/+13
| | | | | This will enable us to handle half-stream expiry differently on the client side vs the exit side.
* Merge branch 'circ-react-logs' into 'main'David Goulet2026-03-161-1/+16
|\ | | | | | | | | proto: Add more logging to the new circuit reactors See merge request tpo/core/arti!3776
| * proto: Add more logging to the new circuit reactorsGabriela Moldovan2026-03-121-1/+16
| |
* | Fix word duplicate typosTobias Stoeckmann2026-03-151-1/+1
|/
* 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. ```
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 06:20:45 +0000