| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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 appears often in the arti logs, but is a normal thing to happen.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Note: this commit only contains the removal of the old `CircSyncView`,
and it of course doens't compile. A future commit will replace the
removed file with the `syncview.rs` from the client module.
This change is split over two commits because it makes reviewing easier
(`git mv`ing the new file over the old results in a confusing diff,
because `git` refuses to show it as a move).
|
| |
|
|
| |
This is not just for clients!
|
| |
|
|
|
| |
This will be used in the stream reactor too (and the stream reactor will
eventually replace the corresponding client impl).
|
| | |
|
| |
|
|
|
|
|
| |
With a protocol violation, we have to immediately deal with such event
before emitting anything on the wire.
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]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
| |
Next commit will also move the Relay specific set into the relay module.
These two sets are becoming specific to the reactor as the circuit
reactor communication channel will use AnyChanMsg instead.
Signed-off-by: David Goulet <[email protected]>
|
| |\
| |
| |
| |
| | |
proto: Start handling incoming streams in the relay reactor
See merge request tpo/core/arti!3487
|
| | |
| |
| |
| | |
All this indirection is making me dizzy.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We are about to use `StreamReqInfo` for exit streams too.
|
| |/
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Using a tunnel ID here doesn't make much sense right now, because we
don't yet support exit-side conflux (and when we will, it's unclear
whether the concept of "tunnel" will be applicable, especially if we
refactor things such that multi-path circuits are handled without a
ConfluxSet-like type like we have for clients).
This change forces us to stop using the client-specific
`unwrap_or_shutdown` (because this macro expects `self` to have a tunnel
ID), but IMO that is okay.
|
| | |
|
| |
|
|
| |
This will be used by exits too, so I am moving it out of `client`.
|
| |
|
|
|
|
|
|
|
|
| |
I don't think the previous comment is correct. The main flow control
checks are about receiving SENDME/XON/XOFFs, and ensuring that we don't
receive too many of them. This all happens in the reactor.
In theory the stream should be checking that we don't receive too many
DATA messages for how many stream SENDMEs we've sent. But this is broken
due to arti#2100. We do check this in the halfstream code though.
|
| |
|
|
|
|
|
|
| |
This sort makes it so that that blocking and unblocking are always
ordered in a sensible way with respect to sending data. This might
help simplify padding machines a bit.
Prerequisite for #2190
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| | |
proto: Remove half-streams when they expire.
Closes #264
See merge request tpo/core/arti!3267
|