| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Replaced `once_cell::unsync::Lazy` with `std::cell::LazyCell`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Fixes #2024
|
| | | |
| | |
| | |
| | | |
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.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
tor-proto: Address a handful of conflux TODOs
See merge request tpo/core/arti!3045
|
| | |
| |
| |
| |
| | |
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)
|
| |\ \
| |/
|/|
| |
| | |
Bump rusqlite dependency to 0.36.0
See merge request tpo/core/arti!3041
|
| | | |
|
