| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
These fields aren't public so this doesn't have semver impacts.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In a moment, we're going to want to transform the field arguments.
That would leave us open to bugs like this:
valid_after: valid_after.into(),
fresh_until: fresh_until.into(),
valid_until: valid_after.into(),
We'll sort out the indentation later in this branch.
|
| | | |
| | |
| | |
| | |
| | | |
This (briefly) regresses the documentation, but it's going to appear
again when we derive the methods.
|
| |/ / |
|
| | |
| |
| |
| |
| |
| |
| | |
We decided to move away from the `Error` + `ErrorDetail`
all-encompassing enum design, and will use `anyhow::Error` in more
places. When we need to handle specific errors, we will create smaller
more-specific error types in those cases.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Use random_hostname() to pick an (E)SNI
Closes #2210
See merge request tpo/core/arti!3372
|
| | |/
| |
| |
| |
| |
| | |
Closes #2210.
Edited-by: Nick Mathewson <[email protected]>
|
| | | |
|
| |/
|
|
| |
Closes #2067.
|
| |\
| |
| |
| |
| | |
Add more detail on retry times to GuardMgr logging
See merge request tpo/core/arti!3153
|
| | |
| |
| |
| |
| | |
While this is fairly nested, it's short, and most of the complexity is
just in the logging code.
|
| | | |
|
| | |
| |
| |
| |
| | |
The "Next retry time unknown" message can't be hit right now, but could
be if the code changes in the future.
|
| | |
| |
| |
| |
| | |
I don't love shoving such a complicated expression in thiserror, but it
seems nicer than writing the implementation by hand...
|
| |\ \
| | |
| | |
| | |
| | | |
arti: Ignore reload_cfg::test::watch_multiple.
See merge request tpo/core/arti!3364
|
| | |/
| |
| |
| | |
This is flaky, ignoring until #1607 is fixed.
|
| |\ \
| |/
|/|
| |
| | |
proto: Split out IncomingDataCmdChecker as a separate type
See merge request tpo/core/arti!3348
|
| | | |
|