summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit
Commit message (Collapse)AuthorAgeFilesLines
* proto: Add expect(unused) where neededGabriela Moldovan2026-06-292-0/+3
| | | | | | | | | | | Now that relays no longer use `CtrlCmd::AwaitStreamRequests`, some of these fields are unused. I'm leaving them in for now, but we should remove them if they're still unused after we finish the circ reactor impl. I'm not removing `AwaitStreamRequests`, because it will be needed by onion services, when we replace the old client circuit reactor with the new one.
* proto: Support passing a stream request filter to the reactorGabriela Moldovan2026-06-291-1/+47
| | | | | | | | | Relay circuits always need a filter, so it's best to set it via the constructor. Part of #2582 Closes #2577
* tor-proto: pass correct chan msg cmd to `decrypt_outbound()`Steven Engler2026-06-241-0/+20
| | | | | | | | | | Instead of converting the `RelayEarly` message to a `Relay` message, we add a new `RelayMaybeEarlyChanMsg` restricted message set that can hold either. Previously we were passing the wrong channel message command to `decrypt_outbound()`, which would cause the decryption to fail for relay crypto algorithms that use the command.
* proto: Rename LocalApplicationStream for clarityGabriela Moldovan2026-06-231-4/+4
| | | | | See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4139#note_3429586
* proto: Rework error handling in `HopMgr::get_or_spawn_reactor()`Gabriela Moldovan2026-06-231-12/+7
| | | | | | | | | | This reworks `get_or_spawn_reactor()` to return `Error` instead of `ReactorError`. The main change here is that we now have a dedicated `Error::Spawn` variant for `SpawnError`s, instead of mapping these to `ReactorError` (which actually triggers a clean shutdown, which is not quite what we want here).
* proto: Simplify StreamEvent::LocalStreamClosed (fmt)Gabriela Moldovan2026-06-231-1/+6
|
* proto: Simplify StreamEvent::LocalStreamClosedGabriela Moldovan2026-06-231-15/+4
| | | | | This doesn't need to contain the `CloseStreamBehavior` or `TerminateReason`, because we always use the same ones.
* proto: Rename StreamEvent::Closed to LocalStreamClosedGabriela Moldovan2026-06-231-5/+5
| | | | | | | I realized the previous naming was ambiguous. Hopefully this makes it clear that this `StreamEvent` triggers when the MPSC channel connecting the reactor to the local application stream (for example the local TCP connection of the stream, in the case of exit streams) is dropped.
* proto: Implement ClosePendingStream in the stream reactorGabriela Moldovan2026-06-233-5/+40
| | | | Closes #2590
* proto: Add a helper function for handling closed streams (fmt)Gabriela Moldovan2026-06-231-10/+10
|
* proto: Add a helper function for handling closed streamsGabriela Moldovan2026-06-231-6/+22
| | | | This will soon be reused for implementing `CtrlMsg::ClosePendingStream`.
* proto: Add a new StreamReactor control message for closing streamsGabriela Moldovan2026-06-231-3/+25
| | | | | | | | | | | | | | | This will be sent by the FWD reactor. Essentially, this going to be the final control message in the chain `IncomingStream::reject()` -> `RelayCirc::reject()` -> `forward::CtrlCmd::ClosePendingStream`-> `HopMgr::close_pending()` -> `stream::CtrlCmd::ClosePendingStream` -> stream gets removed from the stream map, END sent Part of #2590
* proto: Update docs to clarify where the StreamReactor cell sender isGabriela Moldovan2026-06-231-1/+2
|
* proto: Add a control message for closing pending streams (fmt)Gabriela Moldovan2026-06-231-3/+4
|
* proto: Add a control message for closing pending streamsGabriela Moldovan2026-06-231-1/+40
|
* proto: Replace StreamMsg with a new CtrlMsg typeGabriela Moldovan2026-06-234-26/+32
| | | | | | | This replaces the `StreamMsg` `StreamReactor` sender with a new `CtrlMsg` type. This `CtrlMsg` currently only has a `DeliverStreamMsg` variant (which is the same as the old `StreamMsg` type), but will soon grow another variant, for terminating a stream.
* proto: Update tests to use the new stream exportsGabriela Moldovan2026-06-171-4/+4
| | | | The tests don't compile otherwise.
* maint: Run maint/add_warning to deny string slicesClara Engler2026-06-093-0/+3
| | | | | | | | | | | | This commit executes maint/add_warning with the just added change to deny string slices except in tests. I recommend auditing this by checking out the previous commit followed by running the script yourself and then verifying that the diff is identical to this commit. This commit makes cargo clippy fail. We will add exceptions in the next commit.
* proto: Add a new channel -> circuit queue typeGabriela Moldovan2026-06-081-0/+371
| | | | | | | | | | | | | | | | | | | | | | | This adds new a `CircuitRxSender`/`CircuitRxReceiver` queue type. The corresponding (`Sink`-link) sender and `Stream` implementations prioritize the delivery of `DESTROY` messages, which get delivered immediately, even if there are other messages queued in the underlying MPSC message queue. We are okay with the resulting data loss, because inbound DESTROY can be indicative of malicious activity on the circuit. We choose to err on the safe side, and free up the resources associated with such circuits as soon as possible. DESTROY messages are also sent by relays when they're about to hibernate, and by clients once they've decided to stop using a circuit. In the latter case, the lack of an `RELAY_COMMAND_END_ACK` does mean that this prioritization can cause data loss in cases where the client closes the circuit immediately after END-ing a stream. However, this is a deficiency in the protocol, and not something we want to fix by implementing custom flushing logic in the reactor. See torspec#196 and the discussion in #2490. Part of #2490
* 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
| |
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 01:22:05 +0000