| 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 can happen if we get an unexpected BEGIN_DIR/RESOLVE too, so we
can't hard-code "BEGIN" in the error message.
Context: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4230#note_3439258,
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature-gating has been a source of confusion, and it unnecessarily
complicates the stream message handling flow.
I've previously argued in favour of keeping it, in the spirit of a belt
and braces approach to message validation, but I've been convinced that
in this particular case, the feature-gate is more trouble than it's
worth.
What makes things worse is that the `CircHop::handle_msg()`
function was designed poorly (by yours truly). I plan on refactoring it
at some point, hopefully soon. There is a TODO about this below
its doc comment.
|
| |
|
|
|
| |
See
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4188#note_3432579
|
| | |
|
| |
|
|
|
|
|
| |
Previously, these would fail to parse, because the (WIP) stream reactor
assumed all streams would be exit (BEGIN) streams.
Closes #2613
|
| |
|
|
|
| |
See
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4139#note_3429586
|
| | |
|
| |
|
|
|
| |
This doesn't need to contain the `CloseStreamBehavior` or
`TerminateReason`, because we always use the same ones.
|
| |
|
|
|
|
|
| |
I realized the previous naming was ambiguous. Hopefully this makes it
clear that this `StreamEvent` triggers when the MPSC channel connecting
the reactor to the local application stream (for example the local TCP
connection of the stream, in the case of exit streams) is dropped.
|
| |
|
|
| |
Closes #2590
|
| | |
|
| |
|
|
| |
This will soon be reused for implementing `CtrlMsg::ClosePendingStream`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will be sent by the FWD reactor.
Essentially, this going to be the final control message in the chain
`IncomingStream::reject()` ->
`RelayCirc::reject()` ->
`forward::CtrlCmd::ClosePendingStream`->
`HopMgr::close_pending()` ->
`stream::CtrlCmd::ClosePendingStream`
-> stream gets removed from the stream map, END sent
Part of #2590
|
| | |
|
| |
|
|
|
|
|
| |
This replaces the `StreamMsg` `StreamReactor` sender with a new
`CtrlMsg` type. This `CtrlMsg` currently only has a `DeliverStreamMsg`
variant (which is the same as the old `StreamMsg` type), but will soon
grow another variant, for terminating a stream.
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
I think this makes the code a little easier to follow.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the client-specific half-stream expiry calculation from
the stream reactor (which is meant to be implementation agnostic) with a
call to the new `StreamHandler::halfstream_expiry()`, which abstracts
away the implementation-specific half-stream expiry calculation (for
example, on the client-side, the calculation takes into account the CBT,
which we don't have on the relay side).
Note that there is currently no `StreamHandler` implementation on the
client-side (because we haven't ported the client circuit reactor to the
new reactor yet).
Closes #2410
|
| |
|
|
|
| |
This will enable us to handle half-stream expiry differently on the
client side vs the exit side.
|
| | |
|
| | |
|
| |
|
|
| |
And update the docs
|
| |
|
|
|
| |
Now that CircSyncView no longer needs to know the total number of
streams, we can use it in the new per-hop stream reactor design.
|
| |
|
|
|
| |
This will soon be used for instructing the BWD to send other types of
messages too.
|
| |
|
