| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Move StreamTarget to the tunnel module and the circuit module.
From now on streams will be implemented on tunnels, not circuits.
This moves `StreamTarget` to the tunnel module. A future change will
replace `ClientCirc` with `ClientTunnel` inside `StreamTarget`.
This is mostly code motion, best reviewed with `--color-moved`.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Closes #1690.
|
| |
|
|
|
|
|
|
| |
This moves the `NetParameters -> KistParams` conversion to
`tor-chanmgr`.
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2706#note_3147557
|
| | |
|
| | |
|
| |
|
|
|
| |
This renames UnsupportedStreamOpsHandle to NoOpStreamOpsHandle for
clarity (the old name kind of sounded like the name of an error type).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is unfortunately necessary, because after the channel handshake, we
need to give the channel reactor a `StreamOps` handle to the underlying
stream.
|
| |
|
|
|
|
|
|
| |
Note: this commit makes `tor-proto` depend on `tor-netdir`
(because it adds a `KistParams` type that is buildable from
`NetParameters`, which is defined in `tor-netdir`).
Closes #1729
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This had a TODO about returning a "status indication instead of just ()"
so this commit adds some status indication that we can expand later if
needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `Channel` had two concepts of "closed". There was an atomic
flag that was set to `true` at the end `Reactor::run`, and an
experimental oneshot channel where the sender was dropped when the
reactor was dropped.
This commit consolidates these two using the `oneshot_broadcast` module.
This means that the behaviour is consistent between both "closed"
statuses (`is_closing()` and `wait_for_close()`). A channel is
considered closed when its reactor is dropped.
This also helps progress towards making the channel reactor cancellation
safe (see arti#1756).
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Fixes #1682.
(This involves some noise in the tests.)
|
| |
|
|
|
| |
This is neater and will make changing the type (in a moment) less
noisy.
|
| |
|
|
|
|
|
|
| |
We use the *channel*'s memquota account. This is arguably wrong, but
it's hard to get right now. See #1652.
Change the type of the queue, and the places it's constructed.
The use sites can all stay the same.
|
| |
|
|
|
| |
This gets it as far as the outbound circuit->channel mpsc queue creation.
Also, we provide an accessor for it.
|
| | |
|
| |
|
|
|
| |
Making a channel is going to involve making a memquota Participant,
which can fail.
|
| | |
|
| |
|
|
|
|
|
| |
The memquota arranagements are going to use this.
We *don't* apply this to Channel (or to other types that aren't
already generic over SleepProvider).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| |
|
|
|
|
|
| |
This commit clarifies the documentation of the `peer_cert` parameter in
the `UnverifiedChannel::check` function, in order to reflect that it
represents the certificate presented during the ServerHello in the TLS
handshake and not in the in-protocol CERTS cell.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously ChannelDetails had a double duty: It held elements shared
among the clones of a Channel, and it also held elements shared
between the Channel and the Reactor. But now that Channel doesn't
have to implement Clone, we can more the non-Reactor elements into
Channel itself.
This change may improve cache locality a bit, and should make it a
little easier to follow the channel code.
I've also moved unique_id out of ChannelDetails into Channel _and_
Reactor: it is small, immutable, and used all the time in logging.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Channel was a type that you could Clone that implicitly
its state. Now, Channel always appears as an Arc<Channel>.
This change has several benefits:
* It makes the relationship between Channel struct and the
underlying channel more clear.
* It enables Channel to participate in the RPC system,
where everything has to be an Arc<.>
* It enables us to have a Weak<Channel>, if we ever want to.
* It will let us move various members out of ChannelDetails.
We did this change a while ago with ClientCirc.
|
| |
|
|
|
|
| |
The old code produced a warning from clippy nightly; we may as well
update to use the new associated consts. (They've been there since
Rust 1.4x.)
|
| | |
|
| |
|
|
|
| |
FTR I don't think agree with clippy on this question, but then I often
don't.
|
| |
|
|
|
| |
These messages are very verbose and I doubt anyone will want them,
usually, even when debugging.
|
| |
|
|
|
|
|
|
|
|
| |
This changes the internal representation to be `NonZeroU32` instead of
just `u32`.
Various places where a circuit ID is optional now use `Option<CircId>`.
Fixes a bug in `CircIdRange::sample` that would previously return a
circuit ID of 0, when the rng returned 0x8000_0000 for a low range.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This commit adds a unit test to the `tor_proto::handshake` module,
which tests the behavior when no NETINFO cell is present within a
channel.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation here is perhaps excessively simple: we put
a `oneshot::Sender` in the `Reactor` object, and a
`Shared<oneshot::Receiver>` in the circuit or channel. When
the reactor is dropped, any copy of the `Shared<Receiver>` will
yield `Err(Cancelled)`.
I'm marking these methods as experimental because I'm not sure I've
thought of all the implications here, and we might want to change
things around.
Down the road, these methods might want to yield a `Result<>`
indicating why the reactor was shut down.
This feature was inspired by a request from Saksham Mittal, and a
felt need while working on !1472.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This commit is mostly code movement; I'd recommend reviewing it
with git's `--color-moved` option.
|
| |
|
|
|
| |
Apparently 1.68 now warns when you call into_iter() on something
that's already an iterator. Fair enough. Let's stop doing that.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Unlike C tor, we treat unrecognized commands as reason to kill off
the connection entirely. That's fine; if we need to add an
unrecognized command in the future, we can use VERSIONS to negotiate
it.
Also, if someday we want this code to support relay channels as
well, we can use some type trickery to have that work too.
|
| | |
|
| | |
|
