mirrors/arti.git/crates/tor-proto/src/tunnel/reactor, branch arti-v1.4.3mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.32025-04-29T16:31:09Zproto: Make crypt layers take a ChanCmd argument2025-04-29T16:31:09ZNick Mathewsonnickm@torproject.org2025-04-15T01:14:25Zurn:sha1:1998aa7b6a837bc33d372de22566447f477bf01f
CGO will need this argument so that it can authenticate
the command as part of its crypto operations.
(Trying to meddle with RELAY vs RELAY_EARLY will no longer work!)
proto: refactor RelayCrypt trait into separate traits2025-04-29T16:31:09ZNick Mathewsonnickm@torproject.org2025-04-15T00:01:22Zurn:sha1:3bd64c9308a7f3c7772acc2a42f5349ad0534e17
It seems very likely that, as with client crypto,
we'll want relay crypto to separable into "forward" and "reverse"
objects, so that the two can be used more or less independently.
tor-proto: prevent cc extension during ntor-v3 extend2025-04-24T17:07:31ZSteven Engleropara@torproject.org2025-04-24T15:06:35Zurn:sha1:0efe02eee7c615f0c57cc13bfab0b22b8562b2e0
This was missed in commits ccb65961 and eeda643f. While
`params.ccontrol.is_enabled()` should always be false because of those
earlier commits which ensure we don't enable congestion control, we were
missing the defense-in-depth conditions here that would alert us if we
accidentally did enable congestion control.
tor-circmgr: put vegas cc in `CircParameters` behind `if false`2025-04-23T20:48:35ZSteven Engleropara@torproject.org2025-04-23T17:30:39Zurn:sha1:eeda643f253bf4400db8cb8edcc3706bb26bc111
This means that even with the "flowctl-cc" feature enabled, we shouldn't
try to negotiate congestion control.
tor-proto: only use congestion control if "flowctl-cc" feature is enabled2025-04-23T18:39:16ZSteven Engleropara@torproject.org2025-04-17T03:39:44Zurn:sha1:ccb65961cc5a25c304b240a8cfa40d08c4569713
Congestion control is not completely working correctly, and is not fully
implemented (XON/XOFF). This commit adds a new experimental "flowctl-cc"
feature to enable the congestion control extension during the ntor-v3
handshake.
tor-proto: rename `stream_sendme_required` to `uses_stream_sendme`2025-04-23T18:38:25ZSteven Engleropara@torproject.org2025-04-17T03:03:10Zurn:sha1:33fe8ecdf58657bae552b3c04e8f0c7f14f9c2c7tor-proto: rename `allow_stream_sendme` to `uses_stream_sendme`2025-04-23T18:38:25ZSteven Engleropara@torproject.org2025-04-17T02:54:25Zurn:sha1:6bca46e154084f1f76612bc8dee8706d835c14e3
We use this method to decide whether to allow receiving stream SENDMEs,
and also whether we should send stream SENDMEs.
tor-proto: remove redundant `allow_stream_sendme` check2025-04-23T18:38:25ZSteven Engleropara@torproject.org2025-04-17T02:35:26Zurn:sha1:6e89294246d2e6af4a201bdafeb7fc04769c1194
`OpenStreamEnt::put_for_incoming_sendme()` calls
`StreamSendFlowControl::put_for_incoming_sendme()`, which returns an
error if the `StreamSendFlowControl` is in XON/XOFF mode. So we don't
need this extra check.
tor-proto: initialize `StreamSendFlowControl` based on CC2025-04-23T18:38:25ZSteven Engleropara@torproject.org2025-04-17T02:34:43Zurn:sha1:f5cbfeca59dd323f5ccde1a015dd8ec8fd52fe88
Congestion control tells us whether we should use stream or XON/XOFF
flow control.
tor-proto: new stream entries now take `StreamSendFlowControl`2025-04-23T18:38:23ZSteven Engleropara@torproject.org2025-04-17T02:32:16Zurn:sha1:7d55fbe44e6b9854ee5a20a44e2c0abd7f5dfed2
Previously new stream entries required a `StreamSendWindow`, but to
support other flow control algorithms, we want new stream entries to
take a `StreamSendFlowControl` instead.
This also deduplicates the `StreamSendWindow` creation code.