mirrors/arti.git/crates/tor-proto/src/relay/reactor.rs, branch arti-v1.9.0

proto: Relay circuit reactor now handles AnyChanMsg

2025-12-10T16:04:26Z

Same as the client reactor, a message outside of our restricted set leads to a reactor shutdown. Signed-off-by: David Goulet

proto: Move RelayCircChanMsg into relay module

2025-12-10T16:03:12Z

This follows the move of the client specific object. Signed-off-by: David Goulet

proto: Fix relay/hs-service feature gating (fmt)

2025-12-08T17:40:08Z

proto: Fix relay/hs-service feature gating

2025-12-08T17:39:08Z

Without this, `tor-proto` doesn't compile if you enable the `relay` feature but not `hs-service`.

proto: Move EXTEND handling to catch-all error

2025-12-02T18:17:43Z

Since EXTEND is not used anymore, it's fine to handle it in our catch-all branch for unrecognized/unsupported cells.

proto: Resolve some clippy warnings, remove allows

2025-11-24T17:03:48Z

proto: Update relay reactor documentation

2025-11-24T17:03:48Z

proto: Move a couple of stream-related constants to stream mod (fmt)

2025-11-24T17:03:48Z

proto: Move a couple of stream-related constants to stream mod

2025-11-24T17:03:48Z

proto: Start handling incoming stream requests

2025-11-24T17:03:48Z

The relay reactor is now able to handle incoming stream requests (i.e. cells that open streams). It currently only supports DATA stream requests (BEGIN); support for other stream types (BEGIN_DIR, RESOLVE) will be added later. `Reactor::new()` now returns the futures::Stream of Tor streams, alongside the `Reactor` and `RelayCirc` handle. Whoever calls `Reactor::new()` is responsible for passing the stream of streams over to the task that is meant to handle it ("handle" in this case means either rejecting the stream with a given `END` cell, or accepting it and forwarding the connection between it and the corresponding application stream). IMPORTANT: the above is a bit half-baked! Next on my TODO list is is to iron out the details of how/where this will actually be handled. I am also a bit unsure about the API here: I think it might've been nicer to give the user the ability to obtain this `futures::Stream` from `RelayCirc`, which is, after all, a handle to the reactor? Also on my short-term TODO list is to figure out how conflux will affect this API and usage. And there is another wrinkle here: for incoming DATA stream requests, the handler will need to produce a resulting `DataStream`, which is not yet fully implementation-agnostic (it wraps a `ClientDataStreamCtrl`). This too will be handled in a separate MR.