| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A CircId is now a circ_id and a UniqId is a unique_id so we stop
confusing them in the code.
Furthermore, channel_id that are CircId are now circ_id. Channel IDs are
different and encoded internally into a UniqId.
This is the first step to clarify semantic before we change the logging
to log both unique ID and circ ID.
No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This mirrors also the relay reactor. We've introduced the ProtoViolation
into a previous commit which is not an action but rather an "event" that
happened on a circuit.
And so, better semantic. No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
Because of https://gitlab.torproject.org/tpo/core/torspec/-/issues/385
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes the CircuitRx* based solely on the client circuit
message and moves it into the top level of the crate so all reactors can
use them.
The client reactor then upon receiving the message, it converts the
AnyChanMsg into a ClientCircChanMsg. On error, this leads to a shutdown
of the entire reactor due to a fatal error.
In order to pull this off, we added a CircuitAction::Shutdown that is
handled as a priority.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| | |
|
| |
|
|
|
| |
This will be used by relays too, once we modify it to make the `HopNum`
optional.
|
| |
|
|
| |
This is part of an implementation for proposal 368.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Also derives `CIRC_ACTION_COUNT` from the two other constants instead of
hard-coding the value.
|
| |
|
|
|
| |
Besides, it's better if we use the same number for the expected number
of legs as we do in the conflux set impl.
|
| |
|
|
|
|
|
|
|
|
| |
This rewrites `next_circ_action()` yet again, using two layers of
`PollAll`:
* the inner layer drives an individual circuit leg. Each circuit
has a `PollAll` that drives its futures
* the outer layer drives the inner `PollAll`s belonging to the
circuits that form the tunnel
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't really need to return a `HopNum` anymore (because we work out
the join point `HopNum` unconditionally in `next_circ_action`).
|
| |
|
|
|
|
| |
If we poll the ready streams on the join point more than once per
reactor loop, we risk sending more than one DATA cell (which is not
good, because cc might block after the first cell is sent).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes our usage of `FuturesUnordered` in
`ConfluxSet::next_circ_action()` to address two issues:
* a fairness issue, where the futures driven by `FuturesUnordered`
could be starved under some circumstances (#2180)
* a logic error, where we'd explicitly avoid reading from the input
channel if the outgoing `chan_sender` channel was blocked (#2179)
Note that the fixing the latter will cause the reactor to buffer more
into the unbounded `chan_sender` sink, but that *should* be okay,
because no input message should be able cause us to queue cells
excessively.
Closes #2179, #2180
|
| |
|
|
|
|
|
| |
Part of #2180
Note: the code is intentionaly left misindented to make reviewing a
bit easier. A future commit will fix the indentation.
|
| | |
|
| |
|
|
|
|
| |
This simplifies the calling code, which will, in turn, make it easier
for us to simplify the logic in ConfluxSet::next_circ_action() and
abolish the questionable use of FuturesUnordered.
|
| |
|
|
| |
Closes #264
|
| | |
|
| |
|
|
|
|
|
| |
Here we give every Circuit in a conflux set its own
PaddingEventStream, and poll it as appropriate.
We don't yet actually implement the "take an action" code.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This enables us to make the conflux handler logic
implementation-agnostic (we want to avoid using `CircuitCmd` here,
because it is specific to client circuits).
|
| |
|
|
|
|
|
|
|
|
| |
This moves the shared types under `tor_proto::conflux`.
Note: the shared types currently import `CircuitCmd` from `client`. A
future commit will change the signature of `handle_msg` to return
something other than `CircuitCmd` (this will also improve readability,
because in reality, that function can never return most `CircuitCmd`
variants).
|
| |
|
|
|
|
|
| |
`tor_proto::conflux` is where the shared conflux logic will live.
Soon the generic parts of the conflux handlers will be moved there
(whereas the client-specific `AbstractConfluxMsgHandler` impl will
continue living under `tor_proto::client`).
|
| |
|
|
|
|
| |
This will enable us to pull `ConfluxMsgHandler` outside of the `client`
module (this is needed because relays are meant to use this type as
well, but with a different `AbstractMsgHandler`)
|
| |
|
|
|
|
| |
These will be used for validating SWITCH cells.
Part of #2031
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `TunnelId*` types will be reused in the relay reactor (exit relays
need to have the concept of a "tunnel ID" because of conflux).
Now the `relay::reactor` module only has a single import from `client`
(for the `unwrap_or_shutdown` helper, which we should be able to remove
soon). From now, we will avoid importing anything from `client` in the
`relay` module, and instead prefer refactoring the code as needed (to
pull the implementation-agnostic parts outside of `client`).
This commit has no functional changes, just code motion.
|
| |
|
|
|
|
|
| |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| | |
|
|
|
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|