mirrors/arti.git/crates/tor-proto/src/tunnel/reactor, 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:10:30Zproto: Remove element_idx + remove in favor of remove_unchecked().2025-07-25T13:10:30ZGabriela Moldovangabi@torproject.org2025-07-25T11:47:19Zurn:sha1:2f2bc6d3d61da7e3681282a40e50f59c7662b773proto: Replace hand-rolled exactly_one() impl with itertools.2025-07-25T13:10:30ZGabriela Moldovangabi@torproject.org2025-07-25T11:03:24Zurn:sha1:00bb06283948a0695e0f628ce4e7cb363589d383
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.2025-07-25T11:39:51ZGabriela Moldovangabi@torproject.org2025-07-25T11:23:31Zurn:sha1:d8f430977e59063e50c8943bdfde2aa288d24266
This method will enable us to remove some duplicated code, as well as
the `element_idx` function.
Downgrade an XXXX to a TODO.2025-07-23T14:59:51ZNick Mathewsonnickm@torproject.org2025-07-15T12:57:46Zurn:sha1:47bf0a8c4328f540160c146261b95f34e7866133Refactor/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.
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.
tor-proto: add plumbing for sending XON2025-07-17T18:01:47ZSteven Engleropara@torproject.org2025-07-16T19:48:06Zurn:sha1:4bcfcc3cae31f901e828369383e4660778eaa8c6
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: send XOFF messages when the queue grows too large2025-07-16T17:36:43ZSteven Engleropara@torproject.org2025-07-15T04:59:24Zurn:sha1:be5da87e8530a34a88db2a01b42a03431a9df8db