| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The key point is this:
+//! I.e., the timeout tracker tells you when (in the future)
+//! any of the comparisons you have made, might produce different answers.
+//! So, that can be used to know how long to sleep for when waiting for timeout(s).
That's how the code in ipt_mgr.rs uses this. Without this change,
things go wrong in the following case: we've got at least one good
IPT, but not quite enough, and the others are taking too long. Ie,
the timeout for "we should publish" is in the past. We decide to
publish (correctly) but this *past* timeout should be disregarded.
Disregarding past timeouts is correct if the code which is making the
comparisons acts on the timeout when it occurs.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
For the same reason as the allow(unreachable_pub).
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This involves plumbing the duration through. Also it involved
breaking out the multiplication by two into an addition, since if we
were to change the factor we'd want to print the scaled value.
|
| | | |
| | |
| | |
| | |
| | | |
We're going to improve the "establishing_very_recently" one in a
moment.
|
| | | |
| | |
| | |
| | |
| | | |
Add a colon. This is going to be the style for our trace and debug
output.
|
| | | |
| | |
| | |
| | |
| | | |
If the time we're supposed to wait is zero, something has gone wrong.
We'd probably just go round again and loop indefinitely.
|
| | | |
| | |
| | |
| | | |
This is a backstop to stop us just spinning. Instead, we crash.
|
| | | |
| | |
| | |
| | |
| | | |
We never called the `started_establishing_very_recently` machinery.
Do so.
|
| | | |
| | |
| | |
| | |
| | | |
lifetime is passed in the IptSet and doesn't want to be made absolute
here.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This calculation is now done elsewhere: the addition of
IPT_PUBLISH_EXPIRY_SLOP happens in IptSet::note_publication_attempt
and the storage in the manager's data structure is done by
IptManager::import_new_expiry_times.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Without this, it can be a bit confusing since you just get the
output (if any) of all the test runs, concatenated. It seems sensible
to put the framing centrally.
And, this would be helpful if the test fails for any reason.
|
| | | | |
|
| | |/
|/| |
|
| |\ \
| | |
| | |
| | |
| | | |
tor-proto: Resolve a few TODO HSS entries.
See merge request tpo/core/arti!1658
|
| | | |
| | |
| | |
| | |
| | | |
This should be smaller and faster than vec, and save some
allocations. It could also avoid a tiny sidechannel.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
(We try to avoid making tons and tons of copies of a secret key.)
|
| | | |
| | |
| | |
| | | |
This will let avoid some copying inside our HSS code.
|
| | | |
| | |
| | |
| | |
| | | |
There is some similarity, but there's not really a logical way
to combine the two that actually results in less, clearer code.
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
Implement build_auth_clients()
See merge request tpo/core/arti!1642
|
| | | | |
|
| | | |
| | |
| | |
| | | |
cargo fmt, precisely.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
It's not so straightforward to provide this (we'd need to poll the
FusedFuture and make a dummy a Context and so on), but this is just
used once in a test where we can replace it with use of `poll!`
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
Non-working attempt to test onion service configuration.
See merge request tpo/core/arti!1640
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It still matches the start pattern in the same way, but it takes the
_next_ match of the end pattern after the start pattern, and it
allows the end pattern to be absent.
This will make the bridge tests a little more robust, and let the
onion service tests stop saying BEGIN and END.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since config-rs has a bug breaking its support for nested arrays
(see discussion at !1640), we're temporarily changing the format
to a single string with a "=>" in the middle.
I've opened #1058 to put things back as they were once config-rs is
fixed.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The problem here is that, for some reason, the proxy_rule
configuration doesn't actually work. I suspect a bug in
Flatten, since the same configuration works fine if you pass
it to the hsrproxy config directly.
|
| | | | |
|
| | | | |
|