mirrors/arti.git/crates/tor-proto/src/client/reactor, branch arti-v1.6.0 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.6.0 2025-09-30T14:32:14Z padding: Remove post-queue blocker. 2025-09-30T14:32:14Z Nick Mathewson nickm@torproject.org 2025-09-29T15:52:03Z urn: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:14Z Nick Mathewson nickm@torproject.org 2025-09-29T15:38:52Z urn:sha1:dc9b191a547d82417393786bfe43f08dcbb89bc2 proto: Replace magic value with constant (fmt). 2025-09-25T13:40:33Z Gabriela Moldovan gabi@torproject.org 2025-09-24T18:19:28Z urn:sha1:bed12ca97113e848f5731459325c8c27e46fa734 proto: Replace magic value with constant. 2025-09-25T13:40:33Z Gabriela Moldovan gabi@torproject.org 2025-09-24T18:17:35Z urn: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:33Z Gabriela Moldovan gabi@torproject.org 2025-09-24T18:14:18Z urn: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:33Z Gabriela Moldovan gabi@torproject.org 2025-09-23T15:40:35Z urn: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:33Z Gabriela Moldovan gabi@torproject.org 2025-09-23T14:49:37Z urn:sha1:96dee23eb00511be1aacc3b3cfaed57ac30f0974 proto: Add comment explaining why we need the chan_sender readiness check. 2025-09-25T13:40:33Z Gabriela Moldovan gabi@torproject.org 2025-09-23T14:35:30Z urn:sha1:577d2352f3849d44809495b3915636071e678438 proto: Rewrite should_skip_join_point to return bool. 2025-09-25T13:40:33Z Gabriela Moldovan gabi@torproject.org 2025-09-22T11:14:11Z urn:sha1:56c139e5214e68c75ff0dbcc8f697070167f55fe We don't really need to return a `HopNum` anymore (because we work out the join point `HopNum` unconditionally in `next_circ_action`). proto: Avoid polling join point streams more than once. 2025-09-25T13:40:33Z Gabriela Moldovan gabi@torproject.org 2025-09-22T11:02:08Z urn:sha1:fbec140eeb5abb9503acad466d36122cb650f3e3 If we poll the ready streams on the join point more than once per reactor loop, we risk sending more than one DATA cell (which is not good, because cc might block after the first cell is sent).