| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
proto: Stop using tunnel IDs in relay reactor.
See merge request tpo/core/arti!3353
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ /
| |
| |
| |
| | |
We can optimize for the general (N <= 3) case, and avoid a heap
allocation.
|