| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This better matches nearby code.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously when initializing a stream, we constructed most of the
stream-related queues outside of the reactor and passed the relevant
halves of the queues (senders or receivers) into the reactor.
A downside of the above approach is that the reactor may be better
informed about what queues to construct, and how to construct them. For
example the reactor knows what type of flow control that the hop is
using, so it knows whether we need queues for passing rate limits and
drain rates for XON/XOFF flow control.
This commit moves the construction of these queues into the reactor and
passes the relevant halves out of the reactor. In the future we can make
better decisions about which queues are needed depending on the flow
control method used instead of always constructing them (see arti#2068).
Reviewing with `--color-moved` might be helpful as a few lines have been
moved.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Whether a stream queue should be bounded or unbounded is a decision that
needs to be made at runtime depending on the type of flow control used,
not at build-time. Window-based flow control should be bounded and
XON/XOFF flow control should be unbounded.
If we wanted to support both bounded and unbounded queues, it would take
a bunch of boilerplate code to wrap the senders and receivers in enums.
Instead we make the queue always bounded, but use a large bound for
XON/XOFF flow control.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The stream queue length (for messages incoming from the Tor network)
depends on the type of flow control we're using for the hop. Currently
we construct the stream queue outside of the circuit reactor, but we
don't have the flow control information here.
Instead of constructing the stream queue outside of the reactor and
passing the sender into the reactor, we construct the stream queue
inside of the reactor and pass the receiver out of the reactor.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
The common suffix isn't needed.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
tor-proto: Don't run vegas algorithm when a clock stall/jump was detected
Closes #2504
See merge request tpo/core/arti!3967
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This moves the window-based flow control for half-streams out of the
`HalfStream` and into the `HalfStreamWindowFlowCtrl` object.
Now that it's applied only in `HalfStreamWindowFlowCtrl` and not
generally for all half-streams, we no longer apply window-based flow
control to half-streams when they're really using xon/xoff-based flow
control.
|
| | |
| |
| |
| |
| | |
This adds the general structure, and we'll fill it in and use it in a
following commit.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This will make it possible to tell whether a path has been replaced
in the tunnel.
Since the UniqId type might change its representation in the future,
I've documented that we don't guarantee anything about the strings
used to distinguish paths.
|
| | |
|
| |
|
|
| |
Additionally, allow inspecting tunnel paths directly from streams.
|
| | |
|
| |
|
|
|
|
| |
To avoid copying the same information for every circuit,
as suggested by @opara in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3399497
|
| |
|
|
|
| |
It doesn't make sense to do so, as pointed out by @opara in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3398956
|
| | |
|
| |
|
|
| |
This is used in the relay circuit reactor.
|
| |
|
|
|
| |
The new relay circuit reactor test expect the `PeerInfo` to be populated
with the identity keys of the peer, and won't work without this change.
|
| |
|
|
|
| |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3906#note_3397922
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The relay reactor will now reject any EXTEND2 that tries to extend the
circuit to a hop that shares any identities with our previous hop.
Closes #2415
|
| |
|
|
|
| |
This will soon be used for preventing the circuit from being extended to
the previous hop (#2415).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The EXTEND2 handling logic is fairly self-contained, so I'm moving it
outside of the `Forward` handler. This refactoring enables us to add
more context to the handler (i.e. the inbound channel identities needed
for #2415) without cluttering the `Forward` implementation.
I recommend reviewing this commit with `git diff --color-moved`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because of the sorting requirement and the fact that a `KeyMgr` can have
multiple Ntor keys, the caller now explicitly extract the two Ntor keys
it wants from the `KeyMgr` and then creates a `RelayNtorKeys` object
with them.
Future changes (#2495) will move this into a view and warn if there are
more than 2 keys.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |\
| |
| |
| |
| | |
Fix new warnings from Rust 1.95
See merge request tpo/core/arti!3902
|
| | | |
|
