mirrors/arti.git/crates/tor-proto/src/tunnel/circuit.rs, branch arti-v1.4.6mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.62025-07-25T13:48:19Zproto: Add test for ShutdownAndReturnCircuit error condition.2025-07-25T13:48:19ZGabriela Moldovangabi@torproject.org2025-07-25T13:35:53Zurn:sha1:8095c46aadb8a242221a1609371239e17361bc03
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.2025-07-25T13:14:31ZGabriela Moldovangabi@torproject.org2025-07-25T13:14:31Zurn:sha1:a1179040aa4ce325a34436587beb972b1dc4c418
This was fixed in !3091
tor-proto: Temporary measure to disable CGO.2025-07-23T17:47:04ZNick Mathewsonnickm@torproject.org2025-07-23T17:28:15Zurn:sha1:846c2a0583cc82e9f1fb6e1a633faf94db173b1f
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.)
Refactor/simplify HopSettings construction2025-07-23T14:59:51ZNick Mathewsonnickm@torproject.org2025-07-14T19:39:51Zurn:sha1:67ac990a205847e797b000ee474bec3522cd1c2e
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.2025-07-23T14:59:51ZNick Mathewsonnickm@torproject.org2025-07-14T15:37:00Zurn:sha1:d4025dff2f2fecb717099a56bacb2a9b497b110d
Instead call it compatible_with_cgo, which is what we actually
care about in this context.
proto: Send extensions as appropriate to negotiate CGO.2025-07-23T14:59:51ZNick Mathewsonnickm@torproject.org2025-06-11T12:19:28Zurn:sha1:3591c05e34336a210fcae8cb4c69e149c3f88e42
Let's see if it works!
proto: Take format+crypto settings from HopSettings2025-07-23T14:58:47ZNick Mathewsonnickm@torproject.org2025-06-10T23:55:45Zurn:sha1:87b5c7ed464a75c19d7943cc31936146bbb0dace
Since these will be negotiated (or determined as part of negotiation)
they belong in HopSettings.
tor-proto: add the `XonXoffReader` and connect it to the reactor2025-07-17T18:01:47ZSteven Engleropara@torproject.org2025-07-17T05:47:08Zurn:sha1:ac0a34306105bb003573a854c64eedc9cefac51e
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.
Merge branch 'flow-ctrl' into 'main'2025-07-16T18:40:44Zoparaopara@torproject.org2025-07-16T18:40:44Zurn:sha1:1a4020ac0b96e77d79236645df5703337d92bd42
tor-proto,tor-cell: Code refactoring and add support for sending XOFF messages
See merge request tpo/core/arti!3094proto: Add some docs for the conflux stream tests.2025-07-16T17:40:21ZGabriela Moldovangabi@torproject.org2025-07-16T14:30:05Zurn:sha1:310301e1759f1c45803fc6ec446a29670f6e30fe