summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* | | | 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.
| * | | | proto: Move IncomingStream* types to shared moduleGabriela Moldovan2025-11-243-305/+300
| | | | |
| * | | | proto: Make the forward -> backward reactor chan boundedGabriela Moldovan2025-11-243-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This MPSC channel now has zero buffering, because if the backward reactor can't send the cell, the forward reactor must immediately stop reading from its inputs (note that the backward reactor's Tor channel towards the client *does* have a buffering layer).
| * | | | proto: Let cell_rx carry more than just stream dataGabriela Moldovan2025-11-242-21/+46
| | | | | | | | | | | | | | | | | | | | | | | | | There are other types of messages (like circuit-level SENDMEs) that need to be handled in the backward reactor too.
| * | | | proto: Give RelayReactor and BackwardReactor a RuntimeGabriela Moldovan2025-11-242-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | We will soon need a handle to the runtime in BackwardReactor (we need a time provider to call `note_sendme_received()`).
| * | | | proto: Don't poll PollAll unless we can write to chanGabriela Moldovan2025-11-241-14/+9
| | | | | | | | | | | | | | | | | | | | | | | | | We need to avoid reading from all of these if the chan_sender isn't ready, because otherwise we can't provide backpressure.
| * | | | proto: Use CircuitCellSender in the backward reactorGabriela Moldovan2025-11-241-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The backward reactor needs this for handling padding (because it may need to e.g. put the chan sender in a blocked state). Note that `CircuitCellSender` has an underlying `SometimesUnboundedSink`, so from now on we must be very careful and avoid writing to the `chan_sender` if it's not ready (because otherwise we can end up buffering unboundedly). The next commit will add some extra checks against reading from futures::Streams that might cause us to write to the `chan_sender` sink (futures::Sink).
| * | | | proto: Return early if the cell is unrecognizedGabriela Moldovan2025-11-241-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewriting the code this way reduces the indentation level for the "recognized cell" case (which is not yet implemented, but will be very soon), thereby making it more readable.
* | | | | Merge branch 'p2-item-rest-with' into 'main'Ian Jackson2025-12-023-10/+16
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | tor-netdoc: Rework ItemValueParseable, netdoc(rest, with) See merge request tpo/core/arti!3502
| * | | | | parse2: ItemValueParseable, netdoc(object, rest): docs: state signatureIan Jackson2025-12-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3502/diffs?commit_id=f9a6d90ec6d5abf2958534d2c100c84f325e3634#2525aaf11b44162850101813478c4734160e11fa_920_919
| * | | | | parse2: ItemValueParseable, netdoc(object, rest): docs: clarify errorsIan Jackson2025-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The error is not really discarded (which would seem to mean ignoring it). The erorr *value* is discarded and is replaced with a less informative error value.
| * | | | | parse2: ItemValueParseable, netdoc(object, rest): docs: fix typoIan Jackson2025-12-021-1/+1
| | | | | |
| * | | | | parse2: ItemValueParseable, netdoc(rest, with): reworkIan Jackson2025-12-023-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The path in `with` must always be a module, not a function, because we need to use it for encoding too. In the case of `rest`, it's probably sensible to require a different function name, given that the semantics are subtly different to those of `rest` without `with`, since the latter can only get a single word but with `rest` you get the whole line.
| * | | | | parse2: ItemValueParseable, netdoc(rest): docs: clarify behaviourIan Jackson2025-12-021-1/+1
| | | | | |
* | | | | | Merge branch 'static-arti-rpc-client-lib' into 'main'Nick Mathewson2025-12-021-1/+1
|\ \ \ \ \ \ | |/ / / / / |/| | | | | | | | | | | | | | | | | Added `staticlib` crate-type to arti-rpc-client-core which is needed for iOS. See merge request tpo/core/arti!3523
| * | | | | Added `staticlib` crate-type to arti-rpc-client-core which is needed for iOS.Benjamin Erhart2025-12-021-1/+1
|/ / / / /
* | | | | Merge branch 'rm-semver' into 'main'Alexander Hansen Færøy2025-12-027-22/+0
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Remove semver.md files post-release See merge request tpo/core/arti!3520
| * | | | | Remove semver.md files post-releaseGabriela Moldovan2025-12-027-22/+0
| | | | | |
* | | | | | Merge branch 'cargo-updates' into 'main'Alexander Hansen Færøy2025-12-022-208/+206
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | release: Bump metrics-exporter-prometheus See merge request tpo/core/arti!3521
| * | | | | | Revert "release: Bump criterion to 0.8.0"Gabriela Moldovan2025-12-022-58/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See #2281 This reverts commit c00d381068cd8b88d6b12d8c7be8d4e1dafc828d.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 14:49:28 +0000