| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It was decided that the comparison chain was actually preferrable for
readability. So instead, we're just `allow`ing it until it stops being
a problem.
Signed-off-by: hashcatHitman <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a comparison chain in
`tor_proto::util::poll_all::test::ResolveAfter::poll` which was causing
a clippy warning. The lint in question, `clippy::comparison_chain`, was
a `clippy::style` lint in 1.85.1 and got moved to `clippy::pedantic` in
1.87.0 (see [rust-clippy!14219]).
Since some of us (like me) develop on MSRV, I'm fixing this lint now.
Gabi didn't have any strong opinions on whether I did it like this or
with an `allow` attribute, so I decided this was better since it means
we don't have to come back later just to remove the `allow`.
It should be noted that using a match like this can sometimes be a
performance regression (see [rust-clippy#5354] and [rust-clippy!6390]).
I would expect in this case the effect will be very little, if any, but
if tests in `tor_proto::util::poll_all::test` start taking much longer
and having an impact on CI or something, this could be why.
[rust-clippy!14219]: https://github.com/rust-lang/rust-clippy/pull/14219
[rust-clippy#5354]: https://github.com/rust-lang/rust-clippy/issues/5354
[rust-clippy!6390]: https://github.com/rust-lang/rust-clippy/pull/6390
Signed-off-by: hashcatHitman <[email protected]>
|
| |\
| |
| |
| |
| | |
proto: Move flow_ctrl module under stream.
See merge request tpo/core/arti!3335
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`StreamFlowCtrl` is no longer accessible via `tor_proto::client`, so I
had to update one of the (doc) imports with its new path
Also, I had to change a couple of imports to use `DataWriter` and
`DataStream` from `crate::client::stream` instead of
`crate::client::stream::data`, because the latter is not visible from
`flow_ctrl` anymore.
|
| | | |
|
| | |
| |
| |
| | |
This will be used by exits too, so I am moving it out of `client`.
|
| | |
| |
| |
| |
| | |
This will house the implementation-agnostic stream types and
functionality.
|
| |/
|
|
|
|
|
| |
Everybody should use create_firsthop() and extend(), and let
tor-proto decide which handshake is best.
Closes #1990.
|
| |\
| |
| |
| |
| | |
Apply maybenot padding to channels
See merge request tpo/core/arti!3314
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
With this commit we now actually generate padding when we're told to.
|
| | | |
|
