summaryrefslogtreecommitdiff
path: root/crates/tor-proto
Commit message (Collapse)AuthorAgeFilesLines
...
* | proto: Feature-gate UserMsgHandler.Gabriela Moldovan2025-08-051-1/+3
| |
* | proto: Return a more specific error message from allow_stream_requests.Gabriela Moldovan2025-08-052-5/+8
| | | | | | | | | | | | | | Previously the error message would say `Single circuit getter on multi path tunnel`. The new error message makes it clearer that calling `ClientTunnel::allow_stream_requests()` on a multi path tunnel is not supported.
* | proto: Set is_multi_path = true in the tests.Gabriela Moldovan2025-08-051-6/+14
| | | | | | | | | | | | | | | | | | | | This fixes the `allow_stream_requests()` tests which ensures we don't allow incoming streams on multipath tunnels (because we don't currently support it). This also changes `newcirc_ext` to return `ClientTunnel` instead of `Arc<ClientTunell>` (we need to mutate `ClientTunnel` to manually set `is_multi_path` on its inner `ClientCirc`).
* | proto: Avoid using as_single_circ() in the conflux tests (fmt).Gabriela Moldovan2025-08-051-5/+1
| |
* | proto: Avoid using as_single_circ() in the conflux tests.Gabriela Moldovan2025-08-051-3/+2
| | | | | | | | `as_single_circ()` returns an error for multipath tunnels.
* | proto: Fix the tunnel/circuit.rs unit testsDavid Goulet2025-08-052-80/+122
| | | | | | | | | | | | Adapt all tests to use the new ClientTunnel. Signed-off-by: David Goulet <[email protected]>
* | proto: Remove todo!() from StreamTarget::protocol_error()David Goulet2025-08-051-1/+1
| | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | tunnel: Implement start_conversation() for all tunnel typesDavid Goulet2025-08-053-152/+154
| | | | | | | | | | | | | | | | | | | | The BaseTunnel now has a start_conversation() which takes a TargetHop meaning it can be used with a multi path tunnel. The Conversation object has been moved into the tunnel namespace out of the circuit one. Signed-off-by: David Goulet <[email protected]>
* | tunnel: Implement Buildable for ClientTunnelDavid Goulet2025-08-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | In order to pull this off, the Arc requirement needs to go away because the Arc<ClientCirc> is now within the ClientTunnel. This commit also has a rename of the CircuitBuilder to TunnelBuilder in order to reflect the change that it now builds a ClientTunnel. There is a slight rename in tor-proto as well just for accuracy. Signed-off-by: David Goulet <[email protected]>
* | proto: Change PendingClientCirc to yield back a ClientTunnelDavid Goulet2025-08-052-24/+25
| | | | | | | | | | | | And rename it in the process to "PendingClientTunnel". Signed-off-by: David Goulet <[email protected]>
* | proto: Add last_hop() to Tunnel interfaceDavid Goulet2025-08-051-0/+29
| | | | | | | | Signed-off-by: David Goulet <[email protected]>
* | circmgr: New Tunnel object interfaceDavid Goulet2025-08-051-2/+2
| | | | | | | | | | | | | | | | | | | | Introduce the new Tunnel structs that is planned to expose publicly as a replacement to `ClientCirc`. Future commits will make those tunnel objects be used accross the code base up until tor-proto which than handles Circuit directly. Signed-off-by: David Goulet <[email protected]>
* | proto: Move ClientCirc stream functions to ClientTunnelDavid Goulet2025-08-056-483/+456
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to pull this off, some client => tunnel renaming needed to happen including the comments. The send_raw_msg() is an experimental and expert mode method that any tunnel should have access to in order to be able to send whatever message in whatever tunnel type. No behavior changes. Signed-off-by: David Goulet <[email protected]>
* | proto: Add a new ClientTunnel typeGabriela Moldovan2025-08-053-2/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To use the functionality only allowed on single-circuit tunnels (such as `extend*`), callers will have to call `ClientTunnel::as_single_circ()` to obtain a handle to the underlying `ClientCirc`. This is an opinionated design decision that goes against the plan from [!2790]. It stems from my thinking that it would make more sense to keep `ClientCirc`, than to merge it into `ClientTunnel`. If we merge the two, many functions will need become fallible and less ergonomic, because the user of `ClientTunnel` needs to know whether the `ClientTunnel` consists of a single-circuit or not. Providing (fallible) access to the underlying `ClientCirc` of the `ClientTunnel` seems simpler than the alternative. That being said, I am open to switching back to the original plan if this design turns out to be annoying to work with. [!2790]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2790
* | Merge branch 'fix_rustdoc_nightly' into 'main'Nick Mathewson2025-08-051-0/+5
|\ \ | | | | | | | | | | | | Fix errors from rustdoc nightly. See merge request tpo/core/arti!3124
| * | Fix errors from rustdoc nightly.Nick Mathewson2025-08-051-0/+5
| | |
* | | Bump version of tor-basic-utilsIan Jackson2025-08-051-1/+1
| | | | | | | | | | | | This was accidentally omitted from my version bump script.
* | | Version bumps for 1.4.6Ian Jackson2025-08-051-19/+19
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Made with the following shell script: export CARGO='nailing-cargo -Eu' # Non-functional changes only maint/bump_nodep hashx # Special $CARGO set-version -p arti 1.4.6 # Additional features, no breaking changes, depended on in tree $CARGO set-version -p safelog 0.4.8 # Unconditional bump to 0.33.0 xargs -I P <<END $CARGO set-version -p P 0.33.0 tor-error tor-general-addr tor-geoip tor-rtcompat tor-rtmock tor-async-utils tor-config tor-config-path tor-rpc-connect tor-log-ratelim tor-rpcbase tor-memquota tor-units tor-llcrypto tor-bytes tor-protover tor-checkable tor-cert tor-key-forge tor-hscrypto tor-socksproto tor-linkspec tor-cell tor-proto tor-netdoc tor-consdiff tor-netdir tor-relay-selection tor-persist tor-chanmgr tor-ptmgr tor-guardmgr tor-circmgr tor-dirclient tor-dirmgr tor-keymgr tor-hsclient tor-hsservice tor-hsrproxy tor-relay-crypto arti-client arti-relay arti-rpcserver arti-ureq arti-rpc-client-core END
* / Bump derive-deftly to 1.2.0Ian Jackson2025-08-041-1/+1
|/ | | | No upstream changes that break our code.
* proto: Add test for ShutdownAndReturnCircuit error condition.Gabriela Moldovan2025-07-251-0/+47
| | | | | | | This command is supposed to return an error when handled by a tunnel reactor that has more than one circuit. Prevents the `ConfluxSet::take_single_leg()` bug fixed in 00bb0628.
* proto: Remove an already-addressed TODO.Gabriela Moldovan2025-07-251-2/+0
| | | | This was fixed in !3091
* proto: Remove element_idx + remove in favor of remove_unchecked().Gabriela Moldovan2025-07-251-11/+1
|
* proto: Replace hand-rolled exactly_one() impl with itertools.Gabriela Moldovan2025-07-252-52/+27
| | | | | | | This slightly reduces the amount of code we need to maintain. This also drive-by fixes a bug in `ConfluxSet::take_single_leg`, which previously never actually checked if the conflux set was of size one.
* proto: Add a ConfluxSet::remove_unchecked method.Gabriela Moldovan2025-07-251-0/+16
| | | | | This method will enable us to remove some duplicated code, as well as the `element_idx` function.
* tor-proto: Temporary measure to disable CGO.Nick Mathewson2025-07-231-1/+11
| | | | | | | | | | | | | This commit prevents us from ever deciding that another relay supports CGO, which prevents us from trying to negotiate it. It also adds an assertion to make sure that we haven't tried to negotiate it. We can remove this once we're ready to have CGO turned on: right now it's blocked on being able to negotiate CC. I'm adding this so we can merge this branch (so that I can stop rebasing it.)
* Downgrade an XXXX to a TODO.Nick Mathewson2025-07-231-1/+3
|
* Remove now-needless allow(unused).Nick Mathewson2025-07-231-1/+0
|
* Refactor/simplify HopSettings constructionNick Mathewson2025-07-232-60/+108
| | | | | | | We now take an enum describing whether we are doing no negotiation, HsV3 negotiation, or full negotiation. This lets us do away with the notions of default relay crypto, and of declaring post-facto that no negotiation has occurred.
* Rename and invert the sense of requires_stream_level_sendmes.Nick Mathewson2025-07-232-5/+9
| | | | | Instead call it compatible_with_cgo, which is what we actually care about in this context.
* proto: Send extensions as appropriate to negotiate CGO.Nick Mathewson2025-07-233-1/+54
| | | | Let's see if it works!
* proto: Construct CGO instances if that is what is selected.Nick Mathewson2025-07-232-2/+15
|
* proto: Take format+crypto settings from HopSettingsNick Mathewson2025-07-237-54/+58
| | | | | Since these will be negotiated (or determined as part of negotiation) they belong in HopSettings.
* tor-basic-utils: add `assert_val_impl_trait!` macroSteven Engler2025-07-171-2/+5
|
* tor-proto: replace `DataReader`Steven Engler2025-07-172-44/+48
| | | | | | | | | | | | `DataReader` -> `DataReaderInner` `DataReaderNew` -> `DataReader` This means that the `DataReader` now supports XON/XOFF flow control using the `XonXoffReader`. This means that it can receive requests for a new drain rate from the reactor, and can send the new drain rate to the reactor once there is no more stream data queued.
* tor-proto: add `DataReaderNew`Steven Engler2025-07-173-5/+75
| | | | This will later become `DataReader`.
* tor-proto: add `StreamReceiver::is_empty()`Steven Engler2025-07-171-1/+39
|
* tor-proto: add the `XonXoffReader` and connect it to the reactorSteven Engler2025-07-1711-15/+267
| | | | | | | | | | | | The idea here is that the reactor builds an `XonXoffReaderCtrl` for the new stream, and the `XonXoffReaderCtrl` can receive notifications from the reactor's `StreamFlowControl`. The `XonXoffReaderCtrl` can be combined with any `AsyncRead` to build a `XonXoffReader`, essentially wrapping the `AsyncRead` with a type that handles XON/XOFF flow control. Essentially, the reactor gives you a type that allows you to add XON/XOFF flow control support to any `AsyncRead`. We will add this `XonXoffReader` to the `DataReader` in a future commit.
* tor-proto: add plumbing for sending XONSteven Engler2025-07-176-5/+171
| | | | | Nothing actually causes an XON to be sent yet. But this adds the code so that anything holding the `StreamTarget` can request to send an XON.
* tor-proto: move some code into a `approx_stream_bytes_buffered()` fnSteven Engler2025-07-171-6/+11
|
* Merge branch 'flow-ctrl' into 'main'opara2025-07-1618-161/+592
|\ | | | | | | | | tor-proto,tor-cell: Code refactoring and add support for sending XOFF messages See merge request tpo/core/arti!3094
| * tor-cell: add `FlowCtrlVersion::V0`Steven Engler2025-07-161-12/+2
| |
| * tor-proto: send XOFF messages when the queue grows too largeSteven Engler2025-07-166-6/+121
| |
| * tor-proto: add `CongestionControl::uses_xon_xoff()`Steven Engler2025-07-163-0/+19
| |
| * tor-proto: add dedicated types for the incoming stream queueSteven Engler2025-07-1610-24/+275
| | | | | | | | | | XON/XOFF flow control will want to know how many data bytes are queued on a stream, so the new types track that.
| * tor-proto: combine some objects into a `StreamComponents`Steven Engler2025-07-152-28/+64
| | | | | | | | | | | | As we continue adding more functionality to streams like flow control, we'll have more objects to pass around. This tries to group them together.
| * tor-proto: rename `StreamSendFlowControl` and related changesSteven Engler2025-07-155-46/+47
| | | | | | | | | | | | | | | | The plan is to use `StreamSendFlowControl` (now `StreamFlowControl`) for both outgoing and incoming directions, so a name change is needed. This also updates some comments, and renames some related struct fields that have the word "send" in them.
| * tor-proto: adjust `CtrlMsg::SendSendme` and renameSteven Engler2025-07-153-60/+80
| | | | | | | | | | | | | | | | This allows us to extend the command to implement different flow control methods. We could add new command variants for new flow control methods instead, but I think it makes sense to have them be a single command as they will always have a stream ID / hop location in common. This also helps us keep the flow control logic in one place.
| * tor-cell: remove `flowctl-cc` feature and make XON/XOFF cells stableSteven Engler2025-07-152-2/+1
| | | | | | | | | | I don't see any further changes being needed for these types, and it simplifies a lot of future code in tor-proto that uses these types.
* | proto: Add some docs for the conflux stream tests.Gabriela Moldovan2025-07-161-0/+27
| |
* | proto: Explain why the test MockRuntime is behind a mutex.Gabriela Moldovan2025-07-161-1/+6
| |
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-28 11:38:47 +0000