mirrors/arti.git/crates/tor-proto/src/relay.rs, branch main

tor-cell: rename `XonKbpsEwma` to `XonKBpsEwma`

2026-07-30T21:34:23Z

proto: Add newtype wrapper for incoming stream receiver

2026-07-22T12:12:10Z

The inner type is an eyesore, and doesn't really need to be exposed outside of tor-proto (we might even replace it at some point).

proto: Remove RelayCirc::allow_stream_requests()

2026-06-29T13:52:57Z

We don't need it anymore now that `RelayCirc`s always allow incoming stream requests. The previous design, where you could build a `RelayCirc` that didn't allow stream requests, was a leftover from the onion service `ClientCirc` implementation that this was inspired from (onion services *do* need the two to be decoupled, because incoming stream requests are only allowed on the virtual hop, after it's established). Closes #2582

proto: Pass an IncomingStreamRequestFilter factory to the create handler

2026-06-29T13:52:56Z

This implements what we discussed in `doc/dev/notes/relay-streams.md` (lines 218-234): > Currently, to allow incoming stream requests on a circuit, > you first need to call `RelayCirc::allow_stream_requests()` > to install a `CmdChecker` and `IncomingStreamRequestFilter`. > This is not ideal, because `allow_stream_requests()` will need to be > called unconditionally, on each `RelayCirc`, > right after it's created in the `CreateHandler` impl > (which in turn, would mean making `handle_create()` async too, > because `allow_stream_requests()` is async, which wouldn't be great). > > So, the first step here is to rework the `RelayCirc` API to make relay circuits > be constructable with a list of allowed `RelayCmd`s and `IncomingStreamRequestFilter` > from the get-go ([#2582]), and to get rid of `allow_stream_requests()`, > which will enable the `CREATE*` handler to remain non-`async`. > > In any case, the `CREATE*` handler will still require some changes, > because it needs to be initialized with an `IncomingStreamRequestFilter`, I am not sure using an `IncomingStreamRequestFilter` "factory" is necessarily the right approach here, but the circuit `Reactor`'s constructor needs to take an `IncomingStreamRequestFilter`, and `IncomingStreamRequestFilter` is not `Clone` (and FWIW, I think it's better if we don't make it `Clone`). One obvious limitation is that the `IncomingStreamRequestFilter` of the circuit reactor is fixed for the entire lifetime of the circuit. In practice, I don't think this is going to be a problem, because the arti-relay `IncomingStreamRequestFilter` is only going be used for * preventing single-hop exit streams * per-circuit rate-limiting. Both of these checks will require the filter to have access to a recent `NetDir`, which is straightforward if the filter has an Arc (as mentioned in doc/dev/notes/relay-streams.md, `NetDirProvider` has a handy non-async `timely_netdir()` function we can use). And since these checks are based on consensus params, we don't really need to ever update an already-built circuit with a new `IncomingStreamRequestFilter` (because all `IncomingStreamRequestFilter` will have the ability to obtain a fresh `NetDir` as needed). Nevertheless, I left a TODO about this, because I expect this type to change once we figure out all the other pieces needed for #1448.

proto: Implement RelayCirc::close_pending()

2026-06-23T15:58:29Z

Closes #2590

proto: Add a control message for closing pending streams

2026-06-23T15:58:29Z

maint: Run maint/add_warning to deny string slices

2026-06-09T15:36:01Z

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.

tor-proto: have `StreamReqInfo` store a `ReactorStreamComponents`

2026-05-21T16:35:59Z

tor-chanmgr: add support for a `CreateRequestHandler`

2026-04-08T15:29:26Z

Revert "proto: Add a new ToRelayMsg util"

2026-02-12T16:35:14Z

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.