| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
This also clarifies why we reroute cells to `BackwardReactor`.
|
| |
|
|
|
| |
Things will get very confusing if every reactor uses different variable
names for this, so I am renaming it back to input.
|
| |
|
|
|
|
|
|
| |
The channel provider is used to request outgoing channels from the
`ChanMgr` in response to `EXTEND`/`EXTEND2` cells, so it belongs in the
`ForwardReactor`.
(This was leftover from the old circ reactor architecture)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is the first step towards parallelizing stream reads and
writes.
|
| |
|
|
|
| |
This makes it a bit clearer that `cell_rx` is for moving stream data
between `ForwardReactor` and `BackwardReactor`.
|
| |
|
|
| |
The forward/backward terminology is clearer.
|
| | |
|
| |
|
|
|
| |
BackwardReactor is not meant to be used directly (the channel reactor is
supposed to use the `RelayReactor` wrapper instead).
|
| |
|
|
|
| |
`BackwardReactor` now exists alongside `ForwardReactor`,
to make it clearer that they are siblings.
|
| |
|
|
|
| |
We are about to need this, because BackwardReactor will be moved to
another module, and we want to keep its internals private.
|
| |
|
|
|
|
|
| |
This is no longer used, and not having it makes the code less generic
and easier to read, so I'm removing it for now.
If we ever need it again, we can add it back.
|
| |
|
|
|
|
| |
This is the first step towards making `ForwardReactor` and
`BackwardReactor` be siblings (rather than being in a
primary-subordinate relationship).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This sketches out the "dual" relay reactor implementation, which has:
* a `ForwardReactor`, which forwards cells from the client to the exit
* a `BackwardReactor`, which deals with streams, control messages, and
forwarding cells from the exit to the client
The `BackwardReactor` is actually the "primary" reactor. It's the
interface we expose to the channel reactor (via the `RelayReactor`
type-alias), and it is in charge of spawning the "secondary"
`ForwardReactor` task (via its `run()` function).
See the module-level docs from `tor_proto::relay::reactor` for more
details on the inner workings of the two reactors.
This commit also adds the incomplete skeleton of the circuit extension
logic. Once #1599 is implemented, we'll be able to uncomment the
commented code, or replace it, depending on what the corresponding
channel reactor APIs look like.
|
| | |
|
| |
|
|
|
| |
We only have one command right now (`Shutdown`), so this is mostly just
boilerplate.
|
| | |
|
| |
|
|
|
| |
We will need a handle to the runtime to spawn the "secondary" reactor
from the main one.
|
| | |
|
| |
|
|
|
|
| |
There will soon be multiple systems that need to be notified of reactor
shut down, so it's time to change this to a channel type with a
cloneable receiver.
|
| | |
|
| |
|
|
|
|
| |
The TODO is silly, because there will be no "outgoing channel map".
There will be at most *one* outgoing channel, and that is represented by
`Option<Outbound>`.
|
| | |
|
| |
|
|
|
|
| |
We need it for exits and leaky pipe.
Part of #2212
|
| |
|
|
|
|
|
|
|
| |
"Backward" because this reactor will deal with relaying cells in the
backward direction (from exit to client). In addition, this reactor will
deal with stream handling and control/command messages.
We will soon have another, "forward", reactor, relaying cells in the
forward direction.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
A "tunnel" is a higher level concept we'll want to avoid using from now
on when talking about the proto implementation.
|
| | |
|
| |
|
|
|
|
| |
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.
|
|
|
This reorganizes the `relay_tunnel` module as per @dgoulet's
[suggestion].
[suggestion]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3162/diffs#note_3240092
|
