| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
The end result should be:
1. outgoing streams - enable sidechannel mitigations
2. incoming hs streams - enable sidechannel mitigations
3. incoming exit streams - disable sidechannel mitigations
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
We have decided that instead of "uniq_id" in logging, we'll use the
"<domaine>-[<type>]-id" syntax to indicate who is that unique ID.
This commit only renames circuit's unique ID to "circ_uniq_id".
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This commit only affects logging. Whenever possible, log both the UniqId
and CircId.
This also changes the log lines which is now "uniq_id=" and "circ_id="
as the UniqId is internal and circ_id (CircId) is protocol level.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
This will soon be needed for building a `CircSyncView`.
|
| |
|
|
| |
These will be used by the relay code too (for circuit extension).
|
| |
|
|
|
|
|
|
| |
This is just because the generic reactor will soon need a clone of the
CC object, so I am preemptively making this function return a ref to the
underlying `Arc` instead. Technically, it would've been fine to just
kept this method and add a separate one returning `&Arc<Mutex<..>>`,
but I'd prefer keeping the API small.
|
| |
|
|
|
|
| |
Soon it won't need be needed here any more. I'm removing it, because
having redundant handles to the CC state makes it difficult to see
exactly where it's being used from.
|
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The relay reactor needs the cc state to be shared between the inbound
and outbound components (i.e. the forward and backward reactors), so we
need to put the cc state behind a mutex.
There will never be any contention on this mutex in the client impl,
because the client reactor doesn't split the `CircHop` into
`CircHopInbound` and `CircHopOutbound`.
In the future, we should work on trying to reduce the number of locks in
the `CircHop` states.
|
| |
|
|
| |
These will be soon used by relays too.
|
| | |
|
| |
|
|
|
| |
The Inbound/Outbound CircHop states will be used in the relay reactor,
so it's helpful to move some of the `CircHop` impl there.
|
| | |
|
| | |
|
| |
|
|
|
| |
This will be used by relays too, once we modify it to make the `HopNum`
optional.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Unlike the client reactor, the relay reactor uses these components in
separate tasks. Splitting `CircHop` this way enables us to reuse its
parts instead of duplicating them in the relay impl.
Eventually, I'd like us to rewrite the client reactor to follow a
similar pattern.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Implement a usage-based timeout for strongly isolated circuits (prop368)
Closes #2237
See merge request tpo/core/arti!3430
|
| | |
| |
| |
| | |
This is part of an implementation for proposal 368.
|
| | |
| |
| |
| |
| | |
`CircHop::relay_format()` returned the same thing as
`CircHop::relay_cell_format()`.
|
| |/
|
|
|
|
|
| |
I think this was addressed by @opara in
eca15143ba80b789382ba7cbe19601d3b98e42c2.
Spotted while refactoring `CircHop`.
|
| |
|
|
|
|
|
| |
Soon we'll use CircuitCellSender in the relay reactor too (we need to,
because it provides a useful abstraction for handling block/unblock
padding actions, and because it has some handy helper functions such as
`congestion_signals()`).
|
| |
|
|
|
|
| |
This is in preparation for moving `CircuitCellSender` out of the client
module (it makes the next commit easier to review, because
`cell_sender.rs` will be moved without any modifications).
|
| | |
|
| | |
|
| |
|
|
| |
These will be shared with the relay code.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This makes it easier to see which parts are implementation-agnostic
(i.e. do not import from crate::client).
|
| | |
|
| |\
| |
| |
| |
| | |
proto: Move celltypes out of client
See merge request tpo/core/arti!3355
|
| | |
| |
| |
| |
| | |
Some of these are relay-specific, so it makes more sense to pull this
into a top-level module.
|
