mirrors/arti.git/crates/tor-proto/src/tunnel/reactor.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:10:30Zproto: 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.
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.
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!3094conflux: Ensure the min-heap is really a min-heap.2025-07-16T17:40:21ZGabriela Moldovangabi@torproject.org2025-07-14T17:24:11Zurn:sha1:c6185a26617cea8700112716f1f7f98049d13817
The `Ord` impl of `OooRelayMsg` already "reverses" the seqno comparison,
which means previously we were double-reversing it (leading to the ooo
cell heap logic being broken in cases where its size was > 1).
Caught by the new conflux switch handling tests.
tor-proto: add dedicated types for the incoming stream queue2025-07-16T17:36:43ZSteven Engleropara@torproject.org2025-07-15T03:38:23Zurn:sha1:9067118cff859a40772462c20fd0bc44a5e8bedc
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: adjust `CtrlMsg::SendSendme` and rename2025-07-15T05:33:24ZSteven Engleropara@torproject.org2025-07-14T18:04:30Zurn:sha1:0c04fe1d8ac07aec55e450abb6d9ddc5c8b0726e
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-proto: added TODOs for making rate limit stream optional2025-07-10T00:26:23ZSteven Engleropara@torproject.org2025-07-10T00:26:23Zurn:sha1:11a4ee07ab487c34cb6974c9eda4c4c5d2dd8d5etor-proto: establish channel for rate limit updates2025-07-07T17:12:05ZSteven Engleropara@torproject.org2025-06-16T22:28:16Zurn:sha1:dce923d2010f66127a5a68b127778366ef517624tor-proto: Remove unnecessary return.2025-07-07T15:58:27ZGabriela Moldovangabi@torproject.org2025-07-07T15:58:27Zurn:sha1:6672d6eb48c42df25b8de32dc5af60546287e92d