| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-hsclient: Use proper CircParameters
Closes #935
See merge request tpo/core/arti!1340
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As per #935.
I called this "circparameters_from_netparameters" not
"circparameters_from_netparams" because the type is "NetParameters"
not "NetParams".
|
| | |
| |
| |
| |
| | |
These two functions are only slightly different, and benefit from
taking a Fn.
|
| | |
| |
| |
| |
| | |
I looked through the C tor source code and couldn't find any
additional path restrictions.
|
| |/
|
|
| |
One of these is test-related; one is vanguards-related.
|
| |
|
|
|
|
|
| |
I think these should go in `[circuit_timing]`. That section already
has some retry parameters, so is not strictly *timing*.
This is not honoured yet.
|
| |
|
|
|
| |
Previously, this was more likely to select elements that occurred after
other elements that didn't satisfy the predicate.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-circmgr: Fix random_idx_where with empty slice
Closes #918
See merge request tpo/core/arti!1296
|
| | |
| |
| |
| |
| | |
I have verified that this test fails, as expected, when applied
without the corresponding bugfix.
|
| | |
| |
| |
| | |
Fixes #918.
|
| |\ \
| | |
| | |
| | |
| | | |
circmgr: New API to expose estimate-based timeouts.
See merge request tpo/core/arti!1281
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This will help create good timeout values for various onion-service
operations.
|
| | | | |
|
| | |/
|/| |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
| |
This algorithm only looks at circuits until it finds one that
satisfies our needs. To get a random circuit, it just randomizes
the starting point within the pool.
This optimization may help if we let circuit pools grow large.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we'd always try to keep 8 circuits ready. That doesn't
make sense if we are super-busy. Instead, if we run out of
circuits, we double the amount that we try to keep ready, and if we
never go under 80% of our target number, we half the number we try
to keep ready.
We limit the rate of change here, to make sure that we aren't
flapping too much or shrinking too aggressively.
This algorithm is still a mite arbitrary, and will need tuning in
the future.
|
| |
|
|
| |
This will be helpful as we complexify the pool behavior a bit.
|
| |
|
|
|
|
| |
These functions' documentation already says that they don't retry,
and hsclient appears to be where we are concentrating our retry
efforts.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Change log levels of messages from INFO to others
Closes #854
See merge request tpo/core/arti!1172
|
| | |
| |
| |
| |
| |
| | |
This commit changes certain log messages to debug for recoverable errors
and a warn if all such attempts fail, in order to not clutter up the
info messages that end users get to see.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Now ClientCirc is no longer `Clone`, and the things that need it
to be `Clone` instead return and use an Arc<ClientCirc>
We're doing this so that ClientCirc can participate in the RPC
system, and so that its semantics are more obvious.
Closes #846.
Thanks to the type system, this was a much simpler refactoring than
I had feared it would be.
|
| |
|
|
|
|
| |
Previously, we only accepted an OwnedCircTarget, which would have
kept us from getting a circuit that was aimed at a specialized
CircTarget that gave us LinkSpecs in a raw order.
|
| |
|
|
|
|
|
|
|
| |
In one case, we use WeightRole::Exit on circuits that can't
actually be used to exit. This commit adds a comment to explain
why, so that we don't wonder about it in the future, and we have
some indication of whether it's still appropriate.
Closes #785
|
| |
|
|
|
|
| |
This resolves a few dead-code warnings.
Closes #801.
|
| | |
|
| | |
|
| |
|
|
|
| |
thread_rng() isn't Send. We can fix this by not holding it over an
await point.
|
| |
|
|
|
|
|
|
| |
Now
nailing-cargo +stable clippy -p tor-hsclient --all-features --all-targets
actually works.
squash! Add some missing imports
|
| | |
|
| | |
|
| |
|
|
|
| |
This uncovered a bug: NoUsage wasn't correct for Hs circuits because
of its behavior with channel_usage().
|
| |
|
|
| |
(Still, only expose it when experimental-api is enabled.)
|
| | |
|
| |
|
|
|
|
| |
The prediction and scheduling logic here is quite primitive;
we should probably refactor it considerably. This should be good
enough for now, though.
|
| |
|
|
|
|
|
|
| |
We now have support for a pool of pre-build circuits that we can use
for HS-related purposes, and we take circuits from this pool as
needed.
Nothing populates or cleans the circuit pool yet.
|
| |
|
|
|
| |
This is now enough to launch circuits on demand. It still needs to
pre-build the first three hops, and to retry on failure.
|
| |
|
|
|
| |
This only builds the first 3 hops. It can be extended to a fourth
hop later -- or not, depending on the circuit kind.
|
| |
|
|
| |
We'll use this to implement the circuits used by onion circuits.
|
| | |
|
| |
|
|
|
| |
Apparently 1.68 now warns when you call into_iter() on something
that's already an iterator. Fair enough. Let's stop doing that.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Abolish CircMgr::get_or_launch_onion_client and everything to support
it. We have decided that `.onion` diversion ccan't/shouldn't occur in
tor-circmgr. Probably, it should occur much higher up - arti-client
maybe - since it will sometimes need ambient authority (KS_hsc_*).
Now all knowledge of HS connections is in tor-hsclient. This
gets rid of a layering inversion and the trait needed for tor-circmgr
to do the upcall to tor-hsclient.
|
| | |
|
| |
|
|
| |
Like the similar thing in tor-guardmgr.
|