| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| | |
These will be shared with the relay code.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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>`.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
That way we don't need to make halfstream `pub(crate)` (we only really
use it in streammap, and in the client reactor, because of the
`handle_msg()` kludge).
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
|
|
| |
Closes #2067.
|
| | |
|
| |
|
|
|
|
| |
The previous "incoming" terminology was rather ambiguous.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337
|
| | |
|
| |
|
|
|
|
|
| |
This will be used by relays too (for validating incoming messages on
streams).
This is just code motion, so it's best reviewed with `--color-moved`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The incoming one will be used for the exit relay implementation too.
Also, with this change, receiving `CONNECTED` on an incoming stream will
result in a clearer error message. Previously, the check against
receiving `CONNECTED` on an incoming stream was bundled with the
double-CONNECTED check for client data streams, so in the incoming
stream case, the error message was misleading ("Received CONNECTED twice
on a stream.").
|
| |
|
|
|
| |
`Arc` is already in scope, and not fully-qualifying it makes it more
readable.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This makes it easier to see which parts are implementation-agnostic
(i.e. do not import from crate::client).
|
| |
|
|
|
| |
The CmdChecker will be used by relays too, so I am moving it to the
shared `stream` module.
|
| |\
| |
| |
| |
| | |
proto: Fix typo in OutboundRelayLayer docs.
See merge request tpo/core/arti!3346
|
| | |
| |
| |
| |
| | |
`OutboundRelayLayer::decrypt_outbound()` is for decrypting cells moving
*away* from the client (in the "forward direction").
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
proto: Remove an allow that is no longer needed
See merge request tpo/core/arti!3356
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
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.
|