summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src
Commit message (Collapse)AuthorAgeFilesLines
* proto: Add an immediate order for client CircuitEvent orderingDavid Goulet2025-12-101-4/+7
| | | | | | | With a protocol violation, we have to immediately deal with such event before emitting anything on the wire. Signed-off-by: David Goulet <[email protected]>
* proto: Rename CircuitAction and cie to CircuitEventDavid Goulet2025-12-102-75/+67
| | | | | | | | | | This mirrors also the relay reactor. We've introduced the ProtoViolation into a previous commit which is not an action but rather an "event" that happened on a circuit. And so, better semantic. No behavior change. Signed-off-by: David Goulet <[email protected]>
* proto: #[macro_use] be gone!Gabriela Moldovan2025-12-104-2/+4
|
* proto: Rename Circuit{Action/Event}::Shutdown to ProtoViolationDavid Goulet2025-12-103-11/+12
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add TODO in client reactor for bad cellDavid Goulet2025-12-101-0/+6
| | | | | | Because of https://gitlab.torproject.org/tpo/core/torspec/-/issues/385 Signed-off-by: David Goulet <[email protected]>
* proto: Move relay specific unit test to relay moduleDavid Goulet2025-12-102-25/+41
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Relay circuit reactor now handles AnyChanMsgDavid Goulet2025-12-103-12/+14
| | | | | | | Same as the client reactor, a message outside of our restricted set leads to a reactor shutdown. Signed-off-by: David Goulet <[email protected]>
* proto: Make ClientCircChanMsg pub(super)David Goulet2025-12-101-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Move unit tests and minor fixDavid Goulet2025-12-103-24/+23
| | | | | | Move the client specific unit tests into the client module. Signed-off-by: David Goulet <[email protected]>
* proto: Client circuit reactor now handles AnyChanMsgDavid Goulet2025-12-109-34/+51
| | | | | | | | | | | | | | | This commit removes the CircuitRx* based solely on the client circuit message and moves it into the top level of the crate so all reactors can use them. The client reactor then upon receiving the message, it converts the AnyChanMsg into a ClientCircChanMsg. On error, this leads to a shutdown of the entire reactor due to a fatal error. In order to pull this off, we added a CircuitAction::Shutdown that is handled as a priority. Signed-off-by: David Goulet <[email protected]>
* proto: Move RelayCircChanMsg into relay moduleDavid Goulet2025-12-105-27/+29
| | | | | | This follows the move of the client specific object. Signed-off-by: David Goulet <[email protected]>
* proto: Move ClientCircChanMsg into client moduleDavid Goulet2025-12-107-34/+39
| | | | | | | | Next commit will also move the Relay specific set into the relay module. These two sets are becoming specific to the reactor as the circuit reactor communication channel will use AnyChanMsg instead. Signed-off-by: David Goulet <[email protected]>
* proto: Remove unused restricted channel msg setDavid Goulet2025-12-101-26/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* Merge branch 'fix-relay-compile' into 'main'David Goulet2025-12-095-9/+14
|\ | | | | | | | | proto: Fix relay/hs-service feature gating See merge request tpo/core/arti!3534
| * proto: Remove outdated TODO about add_ent_with_id()Gabriela Moldovan2025-12-081-3/+0
| | | | | | | | We now have add_ent_with_id(), so we can just remove the TODO.
| * proto: Fix relay/hs-service feature gating (fmt)Gabriela Moldovan2025-12-081-1/+1
| |
| * proto: Fix relay/hs-service feature gatingGabriela Moldovan2025-12-085-6/+14
| | | | | | | | | | Without this, `tor-proto` doesn't compile if you enable the `relay` feature but not `hs-service`.
* | Remove unnecessary `doc(cfg(...))` attributesNeel Chauhan2025-12-046-9/+0
|/ | | | | | | | | Fixes part of #2193. (Edits from nickm: I selected the cases here that I could verify were correct from immediate context.) Edited-by: Nick Mathewson <[email protected]>
* proto: Add comment about create_firsthop_fastNick Mathewson2025-12-031-1/+2
|
* Merge branch 'relay-streams2' into 'main'David Goulet2025-12-0218-696/+1658
|\ | | | | | | | | proto: Start handling incoming streams in the relay reactor See merge request tpo/core/arti!3487
| * proto: Remove incorrect padding logicGabriela Moldovan2025-12-021-18/+5
| | | | | | | | | | This was all wrong, as mentioned in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3487#note_3296033
| * proto: Add TODO about our TRUNCATE plansGabriela Moldovan2025-12-021-0/+5
| |
| * proto: Move EXTEND handling to catch-all errorGabriela Moldovan2025-12-022-9/+0
| | | | | | | | | | Since EXTEND is not used anymore, it's fine to handle it in our catch-all branch for unrecognized/unsupported cells.
| * proto: Explain why we have the backward sink readiness checkGabriela Moldovan2025-12-021-4/+26
| |
| * proto: Resolve some clippy warnings, remove allowsGabriela Moldovan2025-11-242-6/+3
| |
| * proto: Reword a nonsensical TODOGabriela Moldovan2025-11-241-3/+15
| | | | | | | | | | | | This TODO was copied over from the client reactor, but it doesn't make any sense here (we don't yet handle control messages in the backward reactor).
| * proto: Update relay reactor documentationGabriela Moldovan2025-11-241-8/+79
| |
| * proto: Fix a number of newly broken doc linksGabriela Moldovan2025-11-245-5/+7
| |
| * proto: Appropriately gate STREAM_READER_BUFFER to satisfy clippyGabriela Moldovan2025-11-241-1/+4
| |
| * proto: Adjust docs to refer to the new location of StreamReceiverGabriela Moldovan2025-11-241-1/+1
| | | | | | | | | | | | While we still re-export StreamReceiver from the client module, I want to avoid importing it from there in the implementation-agnostic modules, just to make it clearer we're not using client-specific types.
| * proto: Deduplicate msg_streamid()Gabriela Moldovan2025-11-243-40/+22
| | | | | | | | | | | | | | | | | | | | Initially I wanted to turn `msg_streamid()` into a method on `UnparsedRelayMsg`, but I ultimately decided against it, because it feels like it doesn't belong there (even though intuitively, I would've expected it to handle the mismatch between stream ID and cell command internally). This is because all the `UnparsedRelayMsg` methods return `tor_bytes::Result`, and do not actually do any validation beyond some length checks on the various fields.
| * proto: Remove crate-level STREAM_READER_BUFFER reexportGabriela Moldovan2025-11-242-3/+2
| | | | | | | | All this indirection is making me dizzy.
| * proto: Move a couple of stream-related constants to stream mod (fmt)Gabriela Moldovan2025-11-244-7/+5
| |
| * proto: Move a couple of stream-related constants to stream modGabriela Moldovan2025-11-247-25/+20
| |
| * proto: Start handling incoming stream requestsGabriela Moldovan2025-11-243-28/+666
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * proto: Pass all the padding-related objects to the relay reactorsGabriela Moldovan2025-11-243-2/+24
| | | | | | | | These will need to be handled soon
| * proto: Make send_msg_to_client() take an AnyRelayMsgOuterGabriela Moldovan2025-11-241-4/+5
| | | | | | | | | | This is needed because we will soon have another callsite for it, which will need to pass `AnyRelayMsgOuter`.
| * proto: Add a Tunnel::Relay variant for StreamTargetGabriela Moldovan2025-11-243-10/+114
| |
| * proto: Add WIP constructor for relay sync viewGabriela Moldovan2025-11-241-0/+6
| |
| * proto: Move StreamComponents to top-level stream modGabriela Moldovan2025-11-243-22/+24
| |
| * proto: Move raw under top-level stream modGabriela Moldovan2025-11-243-7/+3
| |
| * proto: Move StreamTarget to stream moduleGabriela Moldovan2025-11-244-163/+177
| |
| * proto: Make StreamTarget take a generic TunnelGabriela Moldovan2025-11-241-42/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is needed because we want to reuse `StreamTarget` and `DataStream` on the relay side too, but to do that, we need to abstract away the tunnel/circuit type (prior to this MR, `StreamTarget` was was client-specific, as it used to wrap a client tunnel). Note that `StreamTarget` needs a handle to the client/relay circuit reactor because it needs to be able to shut down the circuit if a protocol error occurs (cells carrying stream data are parsed late, *outside* of the reactor, so if e.g. a cell fails to parse, the `DataReaderImpl` needs to be able to shut it down), and because it needs to be able to inform the reactor of flow control-related events (such as drain rate update).
| * proto: Make the hop in StreamTarget optionalGabriela Moldovan2025-11-241-6/+6
| | | | | | | | For relays, the hop of the StreamTarget will be set to `None`.
| * proto: Add an IncomingStreamConfig to pass to the reactorGabriela Moldovan2025-11-241-2/+12
| |
| * proto: Rework relay reactor error handlingGabriela Moldovan2025-11-241-8/+15
| | | | | | | | | | | | | | I've made `run()` more similar to its client circuit reactor counterpart (I think the error reporting will be better, and if we ever need to make the reactor public, it will be easier this way because now `run()` doesn't expose the crate-private `ReactorError` type).
| * proto: Rename RelayReactor to ReactorGabriela Moldovan2025-11-243-12/+12
| | | | | | | | | | This is already namespaced under the `relay` module so the `Relay` prefix is redundant.
| * proto: Give RelayCirc a DynTimeProviderGabriela Moldovan2025-11-242-1/+7
| | | | | | | | This will be needed soon.
| * proto: Move StreamReqInfo to stream moduleGabriela Moldovan2025-11-243-55/+60
| |
| * proto: Make the hop in StreamReqInfo optionalGabriela Moldovan2025-11-243-6/+3
| | | | | | | | We are about to use `StreamReqInfo` for exit streams too.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 02:27:32 +0000