mirrors/arti.git/crates/tor-proto/src/client/reactor/conflux, branch mainmirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=main2025-09-25T13:37:41Zproto: Push conflux state checks inside handshake_timeout().2025-09-25T13:37:41ZGabriela Moldovangabi@torproject.org2025-09-15T17:02:40Zurn:sha1:606cd2b256470962ddb57116e12d9bc0daed1505
This simplifies the calling code, which will, in turn, make it easier
for us to simplify the logic in ConfluxSet::next_circ_action() and
abolish the questionable use of FuturesUnordered.
proto: Use ConfluxCmd instead of CircuitCmd.2025-09-04T15:38:59ZGabriela Moldovangabi@torproject.org2025-09-01T14:47:33Zurn:sha1:8272fbcf219e05ef779cb04df7e641781ce2fbb6
This enables us to make the conflux handler logic
implementation-agnostic (we want to avoid using `CircuitCmd` here,
because it is specific to client circuits).
proto: Move abstract conflux handlers outside of the client module.2025-09-04T15:38:59ZGabriela Moldovangabi@torproject.org2025-09-01T13:30:09Zurn:sha1:69c831be5fa607b6ad1c6fa7ba7e0668b82e9e75
This moves the shared types under `tor_proto::conflux`.
Note: the shared types currently import `CircuitCmd` from `client`. A
future commit will change the signature of `handle_msg` to return
something other than `CircuitCmd` (this will also improve readability,
because in reality, that function can never return most `CircuitCmd`
variants).
proto: Move cmd_counts_towards_seqno to a new conflux module.2025-09-04T15:38:59ZGabriela Moldovangabi@torproject.org2025-09-01T13:34:35Zurn:sha1:896d73752f5991d9d8d1e8c85a34cbb9b777894d
`tor_proto::conflux` is where the shared conflux logic will live.
Soon the generic parts of the conflux handlers will be moved there
(whereas the client-specific `AbstractConfluxMsgHandler` impl will
continue living under `tor_proto::client`).
proto: Make the ConfluxMsgHandler constructor take an abstract handler.2025-09-04T15:38:59ZGabriela Moldovangabi@torproject.org2025-09-01T12:56:08Zurn:sha1:e3f17eae5732516c8f529c3951f00ea82dd6f1dc
This will enable us to pull `ConfluxMsgHandler` outside of the `client`
module (this is needed because relays are meant to use this type as
well, but with a different `AbstractMsgHandler`)
proto: Update docs to clarify how we validate SWITCH seqnos.2025-09-04T09:13:55ZGabriela Moldovangabi@torproject.org2025-08-26T11:07:36Zurn:sha1:076c73f2983057a2349fe6d2e66e358d1add0121
Also removes all the TODOs related to #2031 (which is now addressed).
proto: Close tunnel if a leg receives consecutive SWITCH cells.2025-09-04T09:13:55ZGabriela Moldovangabi@torproject.org2025-08-26T10:57:46Zurn:sha1:5852e6b3a47137cc2a578098e0df06ae5454e88c
Closes #2031
proto: Ensure the seqno of the first SWITCH doesn't exceed the init cwnd.2025-09-04T09:13:55ZGabriela Moldovangabi@torproject.org2025-08-22T10:55:07Zurn:sha1:8a93bbb72df2fb68100cd363be0bf3f7bd27c23f
This partially addresses #2031
proto: Store the seqno of last cell delivered in the client conflux handler.2025-09-04T09:13:55ZGabriela Moldovangabi@torproject.org2025-08-26T10:10:04Zurn:sha1:9c397ef056388f3efa25a1ca5ff3f7c40c60d0c4
This will be needed for the SWITCH seqno validation logic.
Part of #2031
proto: Pass the cwnd params to the conflux message handler.2025-09-04T09:13:54ZGabriela Moldovangabi@torproject.org2025-08-22T10:30:01Zurn:sha1:c97a1a8e59d5a46950648162ed6799ab54012ae9
These will be used for validating SWITCH cells.
Part of #2031