| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to use TargetHop instead of HopNum but also to get one
step closer to not depend on a mutable state.
We prefer resolving a TargetHop within the Reactor object in order to
use the circuit list instead of the MutableState path.
The HS service subsystem is modified to use this modified function that
is now async and uses a TargetHop.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is about to be used outside of tor-proto. It is part of the work to
remove the use of HopNum outside tor-proto.
The rules are:
- Inbound requsest to the tor-proto crate, TargetHop must always be
used.
- Within tor-proto, TargetHop is resolved into a HopLocation which is
more precise and based on the tunnel circuit(s).
This is another piece that Conflux will require considering that a
Tunnel might have multiple circuits in the future.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
The Reactor has two functions to resolve both TargetHop into a
HopLocation and then a HopLocation into a (UniqId, HopNum).
This commit simply adds a helper that does both but returns an Option
instead of a Result as it will be used by the reactor command handler
and more in future conflux commits.
Signed-off-by: David Goulet <[email protected]>
|
| |\
| |
| |
| |
| | |
tor-proto: Add `Notify{Sender,Receiver}` channel
See merge request tpo/core/arti!3066
|
| | |
| |
| |
| |
| |
| | |
An async notification channel.
This uses `postage::watch::{Sender,Receiver}` internally.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-proto: Give Circuit a handle to the DynTimeProvider.
See merge request tpo/core/arti!3063
|
| | | | |
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
This will enable us to replace the calls to `Instant::now()` with
`DynTimeProvider::now()` throughout the RTT estimator.
This gives us the ability to mock the time, and test that conflux
leg switching occurs as expected.
|
| | |
| |
| |
| |
| |
| |
| | |
The expanded expression makes it easier to see that
`can_crosscheck_with_current_estimate()` can never return `true` if
`self.ewma_rtt` is `None`, and that the `expect()` from
`is_clock_stalled()` cannot panic.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `RttEstimator` now uses `None` to represent not-yet-measured RTTs.
Previously, all the measured RTTs defaulted to 0, in contradiction with
the `RttEstimator::{min,ewma}_rtt_usec()` docs, which state that both
functions are supposed to return `u32::MAX` if there is no estimate.
Closes #2049
|
| |\ \
| | |
| | |
| | |
| | | |
tor-cell: Fix incorrect XON/XOFF cell command integers
See merge request tpo/core/arti!3061
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| | |
- Made an equality assertion between two constants compile-time, resolving a
TODO.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
|
| |/ |
|
| |
|
|
| |
This uses just a placeholder `Empty` stream for config updates.
|
| |
|
|
|
|
| |
We want the tokio trait to call into the futures trait, rather than
having each trait duplicate the logic of calling into the inner writer.
This is less error-prone.
|
| |
|
|
|
| |
This is a `Writer` rate limiter which can receive rate limit updates
from a `Stream`.
|
| | |
|
| |
|
|
|
| |
Circuits only have one identifier now, so we can remove the second,
now-redundant ID.
|
| |
|
|
| |
Closes #1999
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When adding new circuits to an existing tunnel, we need to fixup the
internal TunnelId of those circuits (otherwise they will have the
TunnelId of the old single-path "tunnel" reactor they were extracted
from using `CtrlCmd::ShutdownAndReturnCircuit`).
Spotted while writing some tests.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This type will help produce better logs (logging just the circuit ID
would make it impossible to correlate said circuit with the tunnel it
belongs to).
|
| |
|
|
|
|
| |
The plan is to reuse this identifier for the future tunnel reactor
updates channel (a channel for sending tunnel status updates to a
central consumer).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the `tor-proto` logs to not be prefixed with a
channel/circuit/stream ID, but rather to have these IDs attached to the
log as structured fields.
This change is in preparation for the switch to using `TunnelId`s in the
tunnel reactor instead of circuit `UniqId`s. The reason for the change
to use structured fields is because future logs will likely need to log
the `UniqId`s of the circuits in a tunnel, which will need to either be
formatted somehow in the logs, or logged as a structured field (the
latter seems like the better option, hence this preparatory change).
IMO we should favor structured fields over formatted strings in the
logs in general, but that is a bigger project, so I am only doing a
spot fix for now.
|
| |
|
|
|
|
|
|
|
|
| |
Currently, a tunnel is uniquely identified by the `UniqId` of the first
circuit added to the tunnel. This works, but the double-meaning of the
`UniqId` is bound to cause confusion in the future (because it blurs the
distinction between tunnels and circuits).
This introduces a new `TunnelId` type which will replace `UniqId` in the
tunnel reactor.
|
| | |
|
| | |
|
| |
|
|
|
| |
We're about to add a test that involves circuits built using non-vegas
`CircParams`.
|
| | |
|
| |
|
|
|
|
| |
This is about to become slightly more complex (we need to add a check
for the cc algorithm of the last hop). This refactoring is in
preparation for that.
|
| |
|
|
|
|
| |
Conflux is only supported when prop324 congestion control is enabled, so
we need an accessor for the cc algorithm of a given circuit hop in order
for the conflux code to be able to check *which* cc algorithm is in use.
|
| |
|
|
|
|
| |
This doesn't really change anything, but removing the `.clone()` makes
it a bit more obvious that copying the `*Params` is a lightweight
operation.
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't plan to implement resumption any time soon, so let's just
remove the TODO for now.
|
| |
|
|
| |
As mentioned in #2002, we don't yet support conflux for onion services.
|
| |
|
|
|
| |
It is the responsibility of the caller to wait until at least one of the
legs completes the handshake.
|
| | |
|
| |
|
|
|
| |
This will be covered by #2031 (we'll implement prop349 as part of the
p112 work).
|
| |
|
|
|
|
| |
All of this is not needed, the actual test is in the loop below.
(I accidentally left this in after refactoring the test in my last MR)
|
