mirrors/arti.git/crates/tor-proto/src/client, branch arti-v1.6.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.6.02025-10-01T02:55:15Ztor-proto: fix comment related to validating stream messages2025-10-01T02:55:15ZSteven Engleropara@torproject.org2025-10-01T02:55:04Zurn:sha1:c50199fb3b4c0bb9e0c4644bf6617cf7f63dd044
I don't think the previous comment is correct. The main flow control
checks are about receiving SENDME/XON/XOFFs, and ensuring that we don't
receive too many of them. This all happens in the reactor.
In theory the stream should be checking that we don't receive too many
DATA messages for how many stream SENDMEs we've sent. But this is broken
due to arti#2100. We do check this in the halfstream code though.
padding: Remove post-queue blocker.2025-09-30T14:32:14ZNick Mathewsonnickm@torproject.org2025-09-29T15:52:03Zurn:sha1:4c6e8698283a393ed5880d8e57c069a11a87e953
We no longer want to _ever_ block non-DATA cells, per discussion
in circuit-padding.md.
Closes #2190.
padding: be less dogmatic in a TODO about where a buffer would go.2025-09-30T14:32:14ZNick Mathewsonnickm@torproject.org2025-09-29T15:38:52Zurn:sha1:dc9b191a547d82417393786bfe43f08dcbb89bc2Sort output events for next_circ_action.2025-09-29T17:00:49ZNick Mathewsonnickm@torproject.org2025-09-29T15:27:29Zurn:sha1:ff1c086eca6f561bbc19a64afdfef317bbc19540
This sort makes it so that that blocking and unblocking are always
ordered in a sensible way with respect to sending data. This might
help simplify padding machines a bit.
Prerequisite for #2190
proto: Replace magic value with constant (fmt).2025-09-25T13:40:33ZGabriela Moldovangabi@torproject.org2025-09-24T18:19:28Zurn:sha1:bed12ca97113e848f5731459325c8c27e46fa734proto: Replace magic value with constant.2025-09-25T13:40:33ZGabriela Moldovangabi@torproject.org2025-09-24T18:17:35Zurn:sha1:86ded4698d646c1d37ac9bab669c6e1f0fd35be2
Also derives `CIRC_ACTION_COUNT` from the two other constants instead of
hard-coding the value.
proto: Use MAX_CONFLUX_LEGS instead of magic number.2025-09-25T13:40:33ZGabriela Moldovangabi@torproject.org2025-09-24T18:14:18Zurn:sha1:b2738c26e67ce03e93551c00c49b0bc45bb090a9
Besides, it's better if we use the same number for the expected number
of legs as we do in the conflux set impl.
proto: Make padding and timeout actions take priority.2025-09-25T13:40:33ZGabriela Moldovangabi@torproject.org2025-09-23T15:40:35Zurn:sha1:3687c9a195146c7f790976c2dda9f075a915d6d7
This rewrites `next_circ_action()` yet again, using two layers of
`PollAll`:
* the inner layer drives an individual circuit leg. Each circuit
has a `PollAll` that drives its futures
* the outer layer drives the inner `PollAll`s belonging to the
circuits that form the tunnel
proto: Add comment emphasizing that the PollAll ordering matters.2025-09-25T13:40:33ZGabriela Moldovangabi@torproject.org2025-09-23T14:49:37Zurn:sha1:96dee23eb00511be1aacc3b3cfaed57ac30f0974proto: Add comment explaining why we need the chan_sender readiness check.2025-09-25T13:40:33ZGabriela Moldovangabi@torproject.org2025-09-23T14:35:30Zurn:sha1:577d2352f3849d44809495b3915636071e678438