| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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]>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The advantage of this over using a `SubprotocolRequest` is that we can
use the type system to ensure it only has subprotocols that are allowed
during a handshake.
|
| |
|
|
|
| |
We never used this, it was just needed because we used to convert to a
`CircParameters` which required this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and also remove `CircNetParameters::as_circ_parameters()`.
We used to call `HopSettings::from_params_and_caps()` when handling
incoming circuit requests, but this didn't really make sense because we
already know exactly what settings we want.
The new `HopSettings::from_handshake_params()` takes the exact settings
we want, which means we can also skip constructing a `CircParameters`
and use the raw consensus `CircNetParameters`.
Most of the code in `CircNetParameters::as_circ_parameters()` has been
migrated in some form to `HopSettings::from_handshake_params()`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This applies to relays too, not just onion services (we need to to
handle BEGIN/BEGIN_DIR/RESOLVE).
|
| | |
|
| |
|
|
|
|
|
| |
We _already_ do not include FLOWCTRL_CC as a listed protocol among
the capabilities we provide, when we make a virtual hop. This
branch will make that behavior even more certain, by not looking at
required-client-protocols any longer.
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Whether a stream queue should be bounded or unbounded is a decision that
needs to be made at runtime depending on the type of flow control used,
not at build-time. Window-based flow control should be bounded and
XON/XOFF flow control should be unbounded.
If we wanted to support both bounded and unbounded queues, it would take
a bunch of boilerplate code to wrap the senders and receivers in enums.
Instead we make the queue always bounded, but use a large bound for
XON/XOFF flow control.
|
| |
|
|
|
|
|
|
|
|
|
| |
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 moves the window-based flow control for half-streams out of the
`HalfStream` and into the `HalfStreamWindowFlowCtrl` object.
Now that it's applied only in `HalfStreamWindowFlowCtrl` and not
generally for all half-streams, we no longer apply window-based flow
control to half-streams when they're really using xon/xoff-based flow
control.
|
| |
|
|
|
| |
Previously we would close the circuit, which isn't great because there
can be other streams in use on the circuit.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Without this, `tor-proto` doesn't compile if you enable the `relay`
feature but not `hs-service`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will be used by relays too, once we modify it to make the `HopNum`
optional.
|
| |
|
