aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src
Commit message (Collapse)AuthorAgeFilesLines
...
* tor-proto: Remove already addressed TODO.Gabriela Moldovan2025-06-101-1/+0
| | | | | This was addressed a while ago, in 09a601aed9aac9effa230701b02ba865b5754469
* tor-proto: Fix bug where the join point is read from the wrong list.Gabriela Moldovan2025-06-101-1/+1
| | | | | | | | If we reach this point and the join point is `None`, it means the conflux set has so far consisted of a single leg. This means we need to assign the last hop of the (only) leg to the join point. This initial leg is in `self.circuits`, not in `legs` (`legs` is the list of *new* legs that are being added to the set).
* tor-proto: Add some conflux-related logging.Gabriela Moldovan2025-06-102-1/+27
|
* tor-proto: Derive Display for RemoveLegReason.Gabriela Moldovan2025-06-101-1/+4
| | | | This will be needed for logging purposes.
* tor-proto: Fix typo in comment.Gabriela Moldovan2025-06-101-1/+1
|
* tor-proto: Remove single-path check from primary_leg_mut.Gabriela Moldovan2025-06-101-3/+4
|
* tor-proto: Also count the *existing* unlinked legs.Gabriela Moldovan2025-06-102-1/+21
| | | | | | | | | | `num_legs` keeps track of the number of legs that have an in-progress conflux handshake. This updates the calculation to count the "initial" leg of the tunnel too (because when converting a single-path reactor to a multi-path one, the existing, "initial" circuit needs to complete the conflux handshake too).
* tor-proto: Allow LINK to be sent regardless of conflux pendingness.Gabriela Moldovan2025-06-102-9/+17
| | | | | If we don't make an exception for LINK cells, we'll never be able to send them, and the circuits will be forever "pending conflux handshake".
* tor-proto: Ensure the existing leg gets a ConfluxMsgHandler.Gabriela Moldovan2025-06-101-16/+24
| | | | | | This fixes a bug where we'd fail to set the `ConfluxMsgHandler` for the initial leg of the `ConfluxSet`, when converting the set from a single-path set to a multi-path one.
* tor-proto: Relax conflux set leg validation.Gabriela Moldovan2025-06-101-47/+12
| | | | | | As per the replacement rules from prop354. Except we can't actually enforce the replacement rules at this level (they'll have to be enforced by the caller).
* tor-proto: Update TODO to say it's about conflux tuning.Gabriela Moldovan2025-06-101-3/+5
|
* tor-proto: Downgrade a few more TODO(conflux) to TODO.Gabriela Moldovan2025-06-102-5/+5
| | | | | We need to eventually tackle all of these, but none of them are critical, so I propose we downgrade them to `TODO`.
* tor-proto: Ensure all conflux legs share the same join point stream map.Gabriela Moldovan2025-06-102-6/+49
| | | | | | | | I really dislike that we're exposing the stream map this way. Ideally we'd have some way of sharing the stream maps without exposing the `StreamMap` in `reactor::conflux`. Closes #2011
* tor-proto: Add a TODO about a further refactoring.Gabriela Moldovan2025-06-101-0/+2
|
* tor-proto: Fixup CircHop docs post-refactoring.Gabriela Moldovan2025-06-101-5/+6
|
* tor-proto: Remove now-addressed TODO.Gabriela Moldovan2025-06-101-4/+0
|
* tor-proto: Introduce CircHopList, hide CircHop internals.Gabriela Moldovan2025-06-103-244/+399
| | | | Most of this is code motion, I recommend reviewing with `--color-moved`.
* tor-proto: Move CircHop to a separate module.Gabriela Moldovan2025-06-102-163/+187
| | | | | | | | | | | | This helps hide the `CircHop` internals, and is the first step towards providing a safer API that aims to reduce contention and prevent deadlocking on the stream map mutex. This change is also in preparation for implementing special handling for the join point of a conflux tunnel (which will involve adding a new `CircHop` API for sharing the stream map of another `CircHop`). I recommend reviewing this diff with `--color-moved`.
* HopSettings: Note relay usage.Nick Mathewson2025-06-101-0/+3
|
* Avoid a bug with HopSettingsNick Mathewson2025-06-102-5/+22
| | | | | | | When negotiation won't occur, we need to represent the fact by disabling any settings that would depend on negotiation. Otherwise we'll wind up with the client thinking everything was supported, and the relay thinking that nothing is.
* Clarify HopSettings documentation.Nick Mathewson2025-06-101-3/+7
|
* Renamed NegotiatedHopSettings -> HopSettingsNick Mathewson2025-06-104-36/+33
|
* Clarify documentation for from_params_and_caps.Nick Mathewson2025-06-101-1/+6
|
* Clarify per-circuitness of CircParametersNick Mathewson2025-06-101-1/+7
|
* proto: Rename a pair of internal functionsNick Mathewson2025-06-103-16/+14
|
* proto: Refactor cc fallback.Nick Mathewson2025-06-103-10/+14
| | | | | The fallback CC algorithm is _always_ fixed-window, and we should only use it when the selected CC algorithm is not supported.
* Move responsibility for choosing extensions into tor-protoNick Mathewson2025-06-102-6/+16
| | | | | | | | | Now tor-circmgr no longer needs to check which Protover capabilities are enabled, or construct a separate CircParameters for each hop. Instead, tor-proto decides whether to use the fallback CC mode, based on whether the target supports FLOWCTRL_CC. Closes #1967.
* proto: Move NegotiatedHopSettings to a higher levelNick Mathewson2025-06-105-59/+72
| | | | | | We will construct this object based on the circuit parameters _and_ on the target's supported protocol versions, so we need to do so when we have both pieces of info.
* proto: Split CircParameters and NegotiatedHopSettingsNick Mathewson2025-06-106-32/+65
| | | | | | | | | | | One type will now represent _the kind of hop we are asking tor-proto to negotiate_; the other will represent _the state of such negotiation_. This doesn't simplify the code much yet, but it will be helpful as we add more and more negotiable settings. Part of #1967
* tor-proto: handle XON/XOFF messages in conflux seqno logicSteven Engler2025-06-091-1/+2
|
* tor-proto: fix bug in `RateLimitedWriter::poll_write`Steven Engler2025-06-082-16/+100
| | | | | | Previously it did not behave correctly when `bucket.max()` was 0 (it would sleep for 0 time instead of infinitely, triggering a debug assertion).
* tor-proto: change `wake_when_bytes_available` to `NonZero<u64>`Steven Engler2025-06-082-6/+8
|
* tor-proto: add additional unit test for `TokenBucket::adjust`Steven Engler2025-06-081-1/+57
|
* tor-proto: improve `TokenBucket::adjust`Steven Engler2025-06-081-42/+87
| | | | The token bucket is now refilled before changing the rate.
* tor-proto: rename `TokenBucket::last_refill` to `added_tokens_at`Steven Engler2025-06-081-18/+18
|
* tor-proto: return `Result` from `tokens_available_at`Steven Engler2025-06-052-32/+66
|
* tor-proto: change `RateLimitedWriter` logic to use user-configurable limitSteven Engler2025-06-052-16/+50
| | | | The user now sets a constant amount of bytes to wait for.
* tor-proto: change `ClaimedTokens::commit_fewer` to `reduce`Steven Engler2025-06-052-21/+14
|
* tor-proto: add `{TokenBucket,RateLimitedWriter}Config` typesSteven Engler2025-06-053-33/+110
|
* tor-proto: add token bucket test for token/duration calcSteven Engler2025-06-051-0/+64
|
* tor-proto: add missing doc comment to `DataWriter::writer`Steven Engler2025-06-051-0/+1
|
* tor-proto: pass the time provider to the `DataWriter`Steven Engler2025-06-053-11/+28
|
* tor-proto: update doc comments for `DataWriter{,Inner}`Steven Engler2025-06-051-21/+25
| | | | | Unfortunately the git diff thinks I moved the struct, but I really only moved the comment.
* tor-proto: rename `DataWriter`Steven Engler2025-06-051-14/+32
| | | | | `DataWriter` -> `DataWriterInner` `DataWriterNew` -> `DataWriter`
* tor-proto: add (what will be) the new `DataWriter`Steven Engler2025-06-051-0/+44
|
* tor-proto: add a `RateLimitedWriter`Steven Engler2025-06-052-0/+328
|
* tor-proto: add a `TokenBucket`Steven Engler2025-06-053-0/+612
|
* De-duplicate circuit ntorv3 extension generation code.Nick Mathewson2025-06-042-61/+40
| | | | Closes #1969.
* *: suppress cognitive_complexity warnings from nightlyNick Mathewson2025-05-291-0/+3
| | | | | | | | | | | | | Apparently clippy nightly is better (or worse?) about detecting complex functions than before, so I'm suppressing these warnings where they occur. I have mixed feelings about these warnings: On the plus side, they really do help to detect functions that are twistier than they need to be. On the minus side, they get confused by tracing macros, and the "allows" do pile up. But on the plus side, those "allows" do provide a way to find functions that need to be refactored, and they are never uglier than the functions they decorate.
* tor-proto: Remove already addressed TODO.Gabriela Moldovan2025-05-281-3/+0
| | | | | There's already a check right above the TODO that does what the TODO asks.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-29 09:55:13 +0000