| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: Rewrite reactor loop to read from all circuits.
Closes #1863
See merge request tpo/core/arti!2817
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This was left over from the refactoring that moved the inner `select`
into the `ConfluxSet` impl.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit updates the `Reactor::run_once()` loop to attempt to read
from (and write to) all of its circuit legs as opposed to just the
primary one.
Note that this slightly changes the behavior of the reactor. Previously,
we'd only read from the control channel if the `chan_sender` was ready,
whereas now the control channel is unconditionally read from, in the
*outer* select. The overall effect is that the control channel can cause
unbounded buffering in the `chan_sender` of each circuit (which can
happen if the `chan_sender` is not ready to send). This was actually how
the reactor worked before the refactoring from !2747, which is
reflected in the `chan_sender` docs:
```rust
/// Sender object used to actually send cells.
///
/// NOTE: Control messages could potentially add unboundedly to this, although that's
/// not likely to happen (and isn't triggereable from the network, either).
chan_sender: SometimesUnboundedSink<AnyChanCell, ChannelSender>,
```
I don't believe this to be a problem, for the reason mentioned in the
`chan_sender` docs, and because the main reason we check for
`chan_sender` readiness is to apply backpressure on senders, which is
not something we need to worry about when it comes to the control
channel. Besides, the control channel is unbounded, so not reading
from it won't stop the senders from sending more commands anyway.
Closes #1863
|
| | |
| |
| |
| |
| | |
This tells the reactor to remove a given circuit from the conflux set,
and will be used to remove the circuits that have been shut down.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Remove semver files for 1.4.1
See merge request tpo/core/arti!2827
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
tor-proto: Remove unnecessary async block.
See merge request tpo/core/arti!2815
|
| | | | |
|
| | |/
| |
| |
| |
| | |
`futures::future::poll_fn` returns a future, so the `async` block isn't
actually necessary.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Make DataStream, and its members, implement Sync.
Closes #1859
See merge request tpo/core/arti!2808
|
| | |
| |
| | |
Co-authored-by: Ian Jackson <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
Also, use static_assertions to enforce that that they
_stay_ Send+Sync.
Closes #1859.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-proto: Add ConfluxSet type in the reactor
See merge request tpo/core/arti!2804
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
As suggested by opara in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2804#note_3165059
|
| | | |
| | |
| | |
| | |
| | | |
It used to be a Reactor, but the `reactor` variable name no longer makes
sense.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This helps us get rid of some unnecessary error handling.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2804#note_3165058
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We definitely don't want to ever allow this.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, sending two `CtrlMsg::Create` to the reactor would cause it
to panic. This makes it so that the double `Create` just leads to the
caller receiving an error response via the completion channel.
Note: this was not triggerable via the network, only via the tor-proto
API. Moreover, the panic was unreachable from the public client API,
because the `PendingClientCirc`/`ClientCirc` typestate makes it
impossible to send a second `Create` (the `PendingClientCirc` becomes
`ClientCirc` after the `Create` completes, and `PendingClientCirc`
doesn't have an API for sending `Create` control messages to the
reactor).
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is the first step toward supporting traffic splitting in the
circuit reactor.
While the logic has changed slightly to support handling circuits
instead of just one, the reactor still only supports `ConfluxSet`s of
size 1, so this should effectively be a no-op. In the future, this code
will be extended to support the conflux-specific cells and to implement
the conflux proto.
The code uses `ConfluxSet::primary_leg()` and `ConfluxSet::single_leg()`
somewhat interchangeably. This is not *currently* a problem
because`primary_leg()` is the same as `single_leg()` for single path
tunnels, but we will need to adjust some of these call sites when we add
support for multipath tunnels (I have left a `TODO(conflux)` for every
dubious call site).
This commit also makes `CtrlMsg::FirstHopClockSkew` fallible: if the
reactor is multipath, it will return `Err(Bug(..))` to the caller (this
error is returned to the caller over the `answer` channel; it does *not*
shut down the reactor)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is an intermediate step in rewriting the reactor to manage a
"conflux set" (a set of linked circuits) rather than a single circuit.
This commit contains no functional changes.
|
| | | |
| | |
| | |
| | |
| | | |
These will soon be functions on `Circuit`, so it's a good time to pull
them out of the reactor impl.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reorders the functions from the `Reactor` implementation in
preparation for moving some of them to `Circuit`. This commit contains
no functional changes and should be reviewed with `git diff
--color-moved`.
A future commit will move part of the `Reactor` impl block to `Circuit`.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
I am moving these handlers into a separate type because they'll need to
be shared with the active `Circuit`, for handling incoming cells.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This represents a circuit "leg", in the conflux sense. The `Circuit`
type will be a helper for implementing tunnel reactors that contain
multiple `Circuit`s forming a conflux set.
The fields from `Circuit` were extracted from the `Reactor` struct. A
future commit will part of the `Reactor` implementation to `Circuit`.
|
| | | |
| | |
| | |
| | | |
For readability
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We will soon have a `ConfluxSet` type. Some of its operations will
return `Bug` (for example, the method for getting the *only* leg of the
conflux set will return a `Bug` if the set has no legs, or more than 1
leg).
This conversion function will make it easier these errors to
`ReactorError`.
|
| |/
|
|
|
| |
This took a little refactoring, since derive_more::Foo
no longer re-exports std::ops::Foo.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Move StreamTarget to the tunnel module and the circuit module.
From now on streams will be implemented on tunnels, not circuits.
This moves `StreamTarget` to the tunnel module. A future change will
replace `ClientCirc` with `ClientTunnel` inside `StreamTarget`.
This is mostly code motion, best reviewed with `--color-moved`.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
We're about to need this in `tor_proto::tunnel` which is from the
Conflux work.
In the spirit of upstreaming as much as possible, it is done now.
|
| |
|
|
|
| |
We will eventually need to expose this in `tor-proto`'s public API, so
it'll need to be an opaque type.
|
