summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit
Commit message (Collapse)AuthorAgeFilesLines
* 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. ```
* proto: Implement EXTEND2 handlingGabriela Moldovan2026-02-051-135/+14
| | | | | | | | To handle EXTEND2, the relay `ForwardHandler` impl spawns a background task, which reports back the result via the `CircEvent` MPSC stream. This stream is polled from the `ForwardReactor` main loop, and each `CircEvent` is passed back to `ForwardHandler::handle_event()` for handling.
* proto: Move CREATE helpers to a shared moduleGabriela Moldovan2026-02-051-0/+63
| | | | These will be used by the relay code too (for circuit extension).
* proto: Add BWD command for receiving newly launched outbound channelsGabriela Moldovan2026-02-051-0/+36
|
* proto: Give handle_meta_msg() a handle to the runtimeGabriela Moldovan2026-02-052-2/+8
|
* proto: Add an implementation-dependent reactor event streamGabriela Moldovan2026-02-052-0/+31
| | | | | This will enable us to obtain implementation-dependent asynchronous events (such as the outcome of an extend handshake).
* proto: Move channel provider out of the generic reactorGabriela Moldovan2026-02-052-68/+1
| | | | | | The channel provider is relay-specific, so I am moving it to the relay `ForwardHandler` implementation. This enables us to get rid of some of the feature gating from the generic reactor.
* proto: Fix misleading SendRelayMsg docsGabriela Moldovan2026-02-051-1/+1
| | | | This was leftover from back when this command was only for Sendmes.
* proto: Remove assumption that we are a relay from BWD docGabriela Moldovan2026-02-041-1/+1
| | | | This was leftover from back when the BWD was a relay-specific type.
* proto: Replace SendSendme with a more general-purpose command (fmt)Gabriela Moldovan2026-02-041-5/+4
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 21:04:13 +0000