The good news is that this tests the succeeding and failing cases,
and even managed to expose an off-by-one error in our hop counting.
The bad news is that these tests have shown even more ways in which
our wait_for code is unreliable, and forced me to slow it down even
harder.
This backend uses the kludged-up^W heuristic-enhanced Pareto
estimator from path-spec.txt section 2.4. See path-spec.txt for
full details on the algorithm. I've tried to note with TODO-SPEC
comments all the things that the spec currently leaves out.
Nothing actually uses this code yet. By the time it's in use, I'd
expect that many of these functions will need to have new
visibilities.
Thanks to cargo's version-2 feature resolver, we can require a
runtime for tests only.
I'm also making it so that the functions that create or fetch
Runtimes only exist when one of the runtime features is enabled.
For now that seems like a better solution than having those
functions exist but panic.
Closes#129.
As with the tor-chanmgr code, the circuit manager is now implemented
using an AbstractCircMgr type that uses traits to abstract the
particular behavior of other types that it uses. (Specifically:
circuits, building circuits, and telling whether one circuit usage
is compatible with another.) Abstracting out the dependencies in
this ways makes it possible to test the circuit manager without
having to actually build real circuits.
This commit also introduces new behavior for handling pending
circuit requests. Upon getting a new request, first we check to see
if there's an existing circuit we can use. If there isn't, we look
for pending circuits and wait for them. If there aren't any pending
circuits we can use, we launch one or more, and wait for them.
So far, that's the same as the old behavior. But here's a change:
if, while we are waiting for some pending circuits, a different
circuit is completed, and it's one we could use, then the task that
was building _that_ circuit will tell us: "please look at this
circuit". This gives us better changes of getting a usable circuit
fast.
Minor changes:
* The Error type in CircMgr no longer uses anyhow; several errors
have been simplified.
* We've gotten more formal about the relationship between circuit
usage and target usage.
dalek-crypto is stuck on rand_core 0.5.1, so we've been stuck too.
This commit introduces a compatibility module so that we can wrap
new rand_core instances to make them backward compatible.
This is fairly ugly and I think I'll need to mess around with the
feature configuration a while until we get something that's pleasant
to develop with. This still seems like a good idea, though, since
we _will_ need to be executor-agnostic in the end, or we'll have no
way to handle wasm or embedded environments.
Later down the road, we'll probably want to use futures::Executor or
futures::Spawn more than having global entry points in
tor_rtcompat. That would probably make our feature story simpler.
Tokio is the default now, since tokio seems to be more heavily used
for performance-critical stuff.
This patch breaks tests; the next one will fix them, albeit
questionably.
Nick Mathewson
David Goulet