| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Update `StreamPollSet` to require that its streams implement
`PeekableStream`, and to not do its own buffering of values read from
the stream.
This avoids an extra layer of buffering for streams that already
buffer a value, and makes the interior state a little simpler and more
robust.
It does have a downside of making the API a little less convenient,
since the caller must do its own `poll_peek` call if it wants a
reference to the item.
* Update `StreamMap` to implement `PeekableStream` for
`OpenStreamEntStream`, as it must to satisfy the updated
`StreamPollSet` API. We have to somewhat constrain the
`poll_ready_streams_iter` API to no longer return both a reference to
the stream and the message. I don't see a way to return both
while satisfying the borrow checker. Luckily we don't really need both
anymore.
* Update the Circuit reactor to handle the updated
`StreamMap::poll_ready_streams_iter` API.
|
| |
|
|
|
| |
This was required to be the same type as `S::Item`. We can just use
`S::Item` directly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bullied by clippy. I'm on the fence whether this is actually an
improvement, or whether I should add an exception.
```
error: consider using `Option<T>` instead of `Option<Option<T>>` or a custom enum if you need to distinguish all 3 cases
--> crates/tor-proto/src/util/stream_poll_set.rs:106:56
|
106 | pub fn remove(&mut self, key: &K) -> Option<(K, P, Option<Option<V>>, S)> {
| ^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#option_option
= note: `-D clippy::option-option` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::option_option)]`
```
|
| |
|
|
|
|
| |
This simplifies the bookkeeping a bit, and clears a path towards
updating the Streams in our StreamPollSet to directly respect flow
control.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We can actually return references here instead of `impl Deref`,
simplifying this code a bit and follow-on code to use this in
StreamPollSet.
|
| |
|
|
|
|
|
|
|
| |
Primarily I wanted to exercise the code path that we get a spurious
wakeup due to a future that was removed from the map later becoming
ready.
I also ended up merging ReadyFut and PendingFut into a more flexible
ValueFut to make this a little nicer.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of wrapping `FuturesUnordered`, which doesn't support efficient
access to its internal futures, keep the futures themselves in our own
HashMap, and use a custom Waker to be notified which futures are ready
to be polled.
*Almost* a pure refactor in this step - the implementation now requires
that keys are `Send + Sync + 'static` so that we can put them inside an
`Arc` and send them over a channel.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Fix two TODO ticket numbers
See merge request tpo/core/arti!2224
|
| | |
| |
| |
| |
| | |
I seem to have mistyped this ticket number. We meant #1397
aka "Circuit reactor isn't great", not some release ticket.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
If only I'd used a macro for these, but that's not entirely
straightforward.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This adds a new `add_ent_with_id` function for adding a new entry to the
`StreamMap`. The existing `add_ent` function auto-generates a new stream
ID, which is not good if we're a hidden service, as stream IDs are
supposed to be chosen by the OP (client). When accepting a new stream,
services, exit relays, and dir auths need to use the stream ID received
in the BEGIN cell (instead of generating a new stream ID).
|
| | |
|
| |
|
|
|
|
|
|
| |
This is mostly code movement; you may want to review it with
`--color-moved`.
I'm doing this so we can also use the function in netdoc for
looking up hsdesc authentication.
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, each individual identity type becomes optional.
The functions that expose them unconditionally are now in a "legacy"
trait that only some downstream types are expected to implement.
There are new convenience APIs in HasRelayIds:
* to return Option<&keytype>,
* to see if one identity-set contains another.
This commit will break several downstream crates! For the
reviewer's convenience, I will put the fixes for those crates into a
series of squash! commits on this one.
tor-netdir
----------
Revise tor-netdir to accept optional identities. This required some
caveats and workarounds about the cases where we have to deal with a
key type that the tor-netdir code does not currently recognize at
all. If we start to add more identity types in the future, we may
well want more internal indices in this code.
tor-proto
---------
In order to make tor-proto support optional identities, there were
fewer changes than I thought. Some "check" functions needed to start
looking at "all the ids we want" rather than at "the two known IDs";
they also needed to accommodate that case where we don't have an ID
that we demand.
This change will also help with bridges, since we want to be able to
connect to a bridge without knowing all of its IDs up front.
The protocol currently _requires_ the two current ID types in some
places. To deal with that, I added a new `MissingId` error.
I also removed a couple of unconditional identity accessors for
chanmgr; code should use `target().identity(...)` instead.
tor-chanmgr
-----------
This is an incomplete conversion: it does not at all handle channel
targets without Ed25519 identities yet. It still uses those
identities to index its internal map from identity to channel; but
it gives a new `MissingId` error type if it's given a channel target
that doesn't have one.
We'll want to revise the map type again down the road when we
implement bridges, but I'd rather not step on the channel-padding
work in progress right now.
tor-guardmgr
------------
This change is mostly a matter of constructing owned identity types
more sensibly, rather than unwrapping them directly.
There are some places marked with TODOs where we still depend on
particular identity types, because of how the directory protocol
works. This will need revisiting when we add bridge support here.
tor-circmgr
-----------
These changes are just relatively simple API changes in the tests.
|
| |
|
|
|
|
|
|
| |
This change was a bit annoying, since most of this code _can't_ fail,
and so the only reasonable response is to wrap the input in an
internal error... except for one case where we're actually encoding
a caller-provided message, so we _do_ want to wrap the EncodeError
from tor_bytes.
|
| |
|
|
|
|
|
|
|
| |
Some of these were for decoding particular objects (we now say
what kind of objects), and some were unrelated tor_cert errors that
for some reason we had shoved into a tor_bytes::Error.
There is now a separate tor_cert::CertError type, independent from
tor_cert's use of `tor_bytes::Error` for parsing errors.
|
| |
|
|
|
|
| |
Failing to encode is fundamentally different from failing to
decode. We now treat those separately, and describe _what_ we failed
to encode or decode.
|
| |
|
|
|
| |
This avoids adding additional information for now; that will come on
the next commits.
|
| |\
| |
| |
| |
| | |
Do not include error source() in display() format.
See merge request tpo/core/arti!598
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
According to doc/Errors.md, and in keeping with current best
practices, we should not include display an error's `source()` as
part of that error's display method. Instead, we should let the
caller decide to call source() and display that error in turn.
Part of #323.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This only affects uses of thread_rng(), and affects them all more or
less indiscriminately. One test does not work with
ARTI_TEST_PRNG=deterministic; the next commit will fix it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This time, our estimator discards outliers, takes the mean of what's
left, and uses the standard deviation to try to figure out how
seriously to take our report of skew/not-skew.
These estimates are still not actually used.
|
