| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
We need this since we want to report certain conditions only when
they happen on a new channel, not if we observe them on a
preexisting channel.
|
| |
|
|
|
|
|
|
| |
Fortunately, we don't need a separate type here: authenticated
clock skew can only come attached to a `tor_proto::Error`.
We also remove skew from `tor_proto::Error::HandshakeCertsExpired`,
since it would now be redundant.
|
| |
|
|
|
|
|
|
| |
of a channel.
At first I wanted to have this information not be a part of channels
at all, but it is a fairly tiny amount of data, and the alternatives
are pretty crufty.
|
| |\
| |
| |
| |
| | |
Downgrade `rlimit` to 0.7.
See merge request tpo/core/arti!449
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Upstream 0.8.2 has broken compilation with Rust 1.53; versions
0.8.{0,1} have been yanked.
Possibly by the time the next arti version comes out, they'll have
fixed this situation, or we'll have upgraded our MSRV.
Upstream issue at https://github.com/Nugine/rlimit/issues/42 .
|
| |\|
| |
| |
| | |
# Conflicts:
# doc/semver_status.md
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
Treat expired/not-yet-valid directory objects as Errors.
Closes #431
See merge request tpo/core/arti!448
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Doing this will make us treat caches that send us these objects as
not-working, and close circuits to them instead of trying over and
over.
The case where we add a document from the cache requires special
handling: it isn't actually a error to find an expired document in
our cache (unless the passage of time itself is erroneous, which is
a debatable proposition at best).
Fixes #431.
|
| | |\|
| | |
| | |
| | | |
# Conflicts:
# doc/semver_status.md
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This lets us say that the UsageMismatch cases in some parts of the
code reflect a programming error (RetryTime::Never), whereas in
other case it reflects another circuit request getting to the
circuit first (RetryTime::Immediate).
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For each case, describe its semantics (in addition to when you would
create it).
Explain the relationship between After and At.
Stop saying "Strategy": we renamed this type to "RetryTime".
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Also add tests for RetryTime comparison functions to make sure they
work as expected.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use the new RetryTime type and its associates to decide how long to
wait (if at all) between attempts to build a circuit.
Closes #421.
Part of #329.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we did not distinguish errors that came from pending
circuits from errors that came from the circuits we were
building. We also reported errors as coming from "Left" or "Right",
instead of a more reasonable description.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We were treating restrict_mut() failures as internal errors, and
using internal errors to represent them. But in fact, these
failures are entirely possible based on timing. Here's how it
happens:
* Two different circuit requests arrive at the same time, and both
notice a pending circuit that they could use.
* The pending circuit completes; both pending requests are notified.
* The first request calls restrict_mut(), and restricts the request
in such a way that the second couldn't use it.
* The second request calls restrict_mut(), and gets a failure.
Because of this issue, we treat these errors as transient failures
and just wait for another circuit.
Closes #427.
(This is not a breaking API change, since `AbstractSpec` is a
crate-private trait.)
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The old version of this function was error-prone, and in fact had
errors: it was too easy to forget to add non-persistent fields, and
that's exactly what we forgot in a few cases
(`microdescriptor_missing`, `circ_history`, and
`suspicious_behavior_warned`).
The new version of this function consumes both of the incoming
Guards, and constructs every field explicitly so that we can't
forget to list any.
Closes #429.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, we treated successfully building a circuit to a guard as
a "success", and any failure, including a directory cache failure,
as a failure. With this change, guards now have separate
success/failure and retry status for circuit usage and directory
usage.
This change is needed for guard-as-directory retry to have
reasonable behavior. Otherwise, when a guard succeeds at building a
circuit, that clears the directory-is-failing status and makes us
retry the guards to quickly.
|
| | | |
| | |
| | |
| | | |
This will help when we give Guards a DirStatus as well.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously the code would do stuff like
```
schedule = RetrySchedule::new(INITIAL_DELAY);
```
which is needlessly verbose, since the schedule already keeps track
of its initial delay.
|
| | |/
|/|
| |
| | |
It's about to be shared between fallbacks and guards.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
| |
Not all of these strictly need to be bumped to 0.2.0; many could go
to 0.1.1 instead. But since everything at the tor-rtcompat and
higher layers has had breaking API changes, it seems not so useful
to distinguish. (It seems unlikely that anybody at this stage is
depending on e.g. tor-protover but not arti-client.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Unlike the rest of the crates, these don't have a "tor-" or "arti-"
prefix, and are potentially used by code outside arti. With that in
mind, it's probably for the best not to bump them to 0.2.0 along
with the rest of our crates.
They have had no changes since 0.1.0 other than refactoring and
changing of clippy lints. Therefore, I'm not bumping the
dependencies from other crates onto these: it's fine whether our
other crates use caret/retry-error 0.1.0 or 0.1.1.
|
| |\
| |
| |
| |
| | |
Run cargo upgrade/update in preparation for 0.2.0
See merge request tpo/core/arti!444
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Implement a directory munger to simulate pathological cases in arti-testing (v2)
Closes #397
See merge request tpo/core/arti!442
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This feature allows us to detect different failing cases for
arti#329 that would otherwise be hard to induce. It works by
filtering consensus directory objects and/or microdescriptor objects
before introducing them to the directory manager.
Closes #397.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This commit uses the `visibility` and `visible` crates to
conditionally make certain structs and their fields public
(respectively). This is incredibly dangerous to use for anything
besides testing, and I've tried to write the documentation for the
feature accordingly.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Replace the next delay field immediately rather than taking it and
_then_ setting it. This way, it's never in an incorrect state.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The older default seems (experimentally) to be ridiculously high.
Generally, if we can't build a circuit within a handful attempts,
that circuit has already timed out... unless there is a fast-failure
condition, in which case we're just hammering the network (or our
view of it.)
Found with `arti-testing` for #329.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if we had launch_parallelism > 1, and we were willing to
retry building a circuit max_retries times, then we'd launch up to
max_retries * launch_parallelism circuits before giving up. Ouch!
With this patch, we try to keep the total number of circuits
planned and attempted to the actual max_retries limit.
Part of #329; found with arti-testing.
|
