| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | | |
I believe this type was made public in error: No other crate uses it,
and no API exposes it.
|
| | | |
| | |
| | |
| | | |
Closes #468.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The `DirBootstrapStatus` type now exposes a blockage() method to
return an `Option<DirBlockage>`.
The blockage types reported are more low-level than I'd like, but
they are IMO good enough for now: we'll want to get experience with
actual vs hypothetical problems before we refine them.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
If there was no partial information, then calling update_progress
will now report a stall in this case, which is not what we want.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A "reset" happens whenever we have to start a download attempt over
-- either because we ran out of retries, or we found something wrong
with the consensus after fetching certificates.
An "error" happens when we have a recoverable error from one or more
directory sources.
A "stall" happens whenever a round of downloads or cache loads leads
to no change in the status.
We don't yet use this as part of our status reporting.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we used the "if-modified-since" time associated with the
consensus download, and/or the "valid-after" time in the consensus
attempt, to put multiple attempts into sequence, and to tell one
from another. But that approach was always a kludge, and will soon
get more unreliable as the DirStatus logic gets a bit more complex.
With this commit, we change separate download attempts to be
identified with an AttemptId that increments whenever we decide to
get a different directory from the one we have. IMO this new code
is _much_ cleaner.
|
| | | |
| | |
| | |
| | | |
This is all crate-internal APIs, fortunately.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is about to become only a _part_ of what defines a DirStatus: a
DirStatus will also include a reset count, and some kind of info
about how long we've gone without progress.
|
| | | |
| | |
| | |
| | |
| | | |
As per discussion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813573
|
| | | |
| | |
| | |
| | | |
Consequential ordering changes.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2814276
Change names and comments and docs everywhere.
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813574
|
| | | |
| | |
| | |
| | |
| | | |
Addresses
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813567
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We need this because it is a type parameter for the types of nf_ito_*.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This lets a caller map the inner value, eg to convert the type.
I don't provide `map` as well as `try_map` now, since I don't need it;
we could add it later if it is desirable (although try_map can always
be used instead).
I was hoping to provide a `TryFrom` instead, but that necesasrily
overlaps with the std conversion impl from IntegerMilliseconds<T> to
IntegerMilliseconds<U> where T == U.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is semantically quite meaningful for these to contain something
that isn't `TryInto<u64>`. (Of course the `Duration` conversion won't
work without that.)
Indeed, this condition was only applied to two out of the three types.
Prompted by being near this code, but not actually necessary for
anything I'm doing here.
|
| | | |
| | |
| | |
| | | |
We're going to need this to use this in the padding timer parameters.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Pending an official value from the spec.
|
| | | |
| | |
| | |
| | |
| | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813565
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
But padding is still not enabled by default.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Nothing geenrates config updates yet.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The main copy of the (global) configuration for the client's channels
is going to have to live here, inside this mutex. So this really
needs to become a struct with names fields.
|
| | | |
| | |
| | |
| | | |
Nothing calls this yet.
|
| | | |
| | |
| | |
| | | |
It turns out that we are going to want this.
|
| | | |
| | |
| | |
| | |
| | | |
We're about to split the main new() function off so write a separate
test for new_disabled().
|
| | | |
| | |
| | |
| | | |
chanmgr is going to want to make one of these from a NetDir.
|
| | |/
|/|
| |
| |
| | |
This avoids confusing bugs where you try to modify the result and
nothing happens!
|
| | |
| |
| |
| | |
of the proxy port.
|
| |\ \
| | |
| | |
| | |
| | | |
Enforce no-ring-in-arti/full (and make it true)
See merge request tpo/core/arti!592
|
| | | |
| | |
| | |
| | | |
This is another consequence of the `ring` license issue; see #493.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implement support for reachable_addrs
Closes #491 and #93
See merge request tpo/core/arti!583
|
| | | | |
| | | |
| | | |
| | | | |
Also, improve its documentation.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now the primary exposed function is `pick_guard` again.
This commit is just function renaming.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
At the site of modify_hop, we now have a comment explaining the
internal-error issue.
To make the internal error less likely, we lower the modify_hop call
in lib.rs into GuardSet, where it can make sure it's looking at the
same filter as was used to select the guard.
The function name "pick_guard_ext" is not permanent; I'm going to
rename it in the next commit.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, the API said "you need to call this in a loop till it
returns false". We did that in one place, but not another.
With the introduction of filters, forgetting to loop here becomes a
bug: so instead, change the behavior of extend_sample_as_needed so
it handles looping itself.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
These all say, in one form or another, "there is no guard filtering;
there is only one selection". That's now false.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The fake network we construct for these tests is small in ways that
can sometimes cause weird behavior with guard filters. We fix this
by adjusting the parameters of the guard selection algorithm
accordingly in the tests.
With these new parameters, #491 no longer occurs.
This commit also adds comments to explain why the parameters are set
as they are.
Closes #491.
|
| | | | | |
|