| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
| |
This should be smaller and faster than vec, and save some
allocations. It could also avoid a tiny sidechannel.
|
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| |
|
|
|
|
|
|
| |
A warning is getting in my way when I run
cargo clippy -p tor-hsservice --all-features
See also
https://gitlab.torproject.org/tpo/core/arti/-/issues/1006#note_2932088
|
| |
|
|
| |
These functions only ever return `Bug` errors.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This commit introduces an `IncomingStreamState` enum, which indicates
whether the stream was accepted, discarded, or rejected, or if it is
still pending. The `is_rejected`/`is_accepted` boolean flags are no
longer needed.
Without this change, we'd need to introduce yet another boolean flag
when we implement `discard()` (for the "discarded" state).
|
| |\
| |
| |
| |
| | |
tor-proto: Replace IncomingStreamMsg with IncomingStreamRequest.
See merge request tpo/core/arti!1477
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The two enums essentially serve the same purpose, so we don't
need both of them.
This also addresses the TODO that says we should return an error if
`accept_data` is called for a RESOLVE stream.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
blocking.
Instead of having 2 version of `StreamTarget::close` (a blocking one and
a nonblocking one), we can just return the `oneshot::Receiver` for
receiving the reactor's response and let the caller of
`StreamTarget::close` decide whether to block.
This allows us to reduce some code duplication in the `IncomingStream`
implementation.
|
| |/ |
|
| | |
|
| |
|
|
|
| |
The behaviour of `IncomingStream::drop` is going to depend on whether
the stream was accepted or not.
|
| |
|
|
|
|
|
|
| |
This is a follow-up from !1451.
This commit solves a `TODO HSS` introduced when `DataCmdChecker` got an
additional constructor (`new_connected`) for creating "pre-connected"
streams. See f6745d31 for more details.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When accepting a new stream, hidden services, exit relays and dirauths
don't wait for a `CONNECTED` cell from the initiator.
This commit adds constructors for building `DataStream`s and
`DataCmdChecker`s that can immediately receive data cells (and don't
expect to receive `CONNECTED` cells at all).
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
These are no longer needed.
|
| |
|
|
|
| |
These are all related to issues that will come up for the service
side of the onion service implementation.
|
| | |
|
| |
|
|
| |
There are some weaknesses and problems here; see TODO notes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea here is that we want to make DataStream visible to the
RPC system without requiring that the RPC session hold the
DataStream itself (or the Reader, or the Writer). We could solve
this problem by making _all_ the state in the DataStream shared,
but that would introduce unnecessary extra locking in our critical
path.
Instead we're creating the notion of a "control handle" that lets
you manage and observe a stream without actually owning the stream.
Right now the only supported functionality is asking for the
stream's circuit.
Part of #847
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now ClientCirc is no longer `Clone`, and the things that need it
to be `Clone` instead return and use an Arc<ClientCirc>
We're doing this so that ClientCirc can participate in the RPC
system, and so that its semantics are more obvious.
Closes #846.
Thanks to the type system, this was a much simpler refactoring than
I had feared it would be.
|
| |
|
|
|
|
|
|
| |
Now
nailing-cargo +stable clippy -p tor-hsclient --all-features --all-targets
actually works.
squash! Add some missing imports
|
| |
|
|
| |
Closes #784.
|
| | |
|
| |
|
|
|
|
|
|
| |
The role of CmdChecker is to verify that messages are arriving at
the appropriate sequence on a stream, with respect to the other
messages that have been received. Once the stream becomes
half-closed, the CmdChecker is also in charge of consuming incoming
messages on the stream and making sure that they are well-formed.
|
| | |
|
| |
|
|
|
| |
This closes #525, and ensures, at last, that we don't parse any
message that we wouldn't accept.
|
| |
|
|
| |
Thanks to rust-analyzer for making this simple.
|
| | |
|
| |
|
|
| |
Onion services (and later, exits and caches) will need this.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
Code motion and the minimal mechanical changes.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/375#note_2783078
|
| |
|
|
| |
We now print slighly more information.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/353#note_2781632
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
My proximate motivation is that tls-api wants its inner streams to be
Debug. But in general, I agree with the Rust API Guidelines notion
that almost everything should be Debug.
I have gone for the "dump all the things" approach. A more nuanced
approach would be possible too.
|
| | |
|
| |
|
|
|
|
| |
This took some refactoring, and gave an opportunity to notice
a few error variants that weren't being used, or didn't mean
what they said on the tin.
|
| | |
|
| | |
|