| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \
| | |
| | |
| | |
| | | |
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`.
|
| |
|
|
| |
`RateLimitedWriter` will use this in a future commit.
|
| | |
|
| |
|
|
|
| |
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)
|
| |
|
|
| |
For conflux, we need to test against vegas.
|
| | |
|
| |
|
|
|
| |
I think this is going to be more of a tuning matter, so it's probably
best tackled after we have a working conflux implementation.
|
| | |
|
