mirrors/arti.git/crates/tor-circmgr/src/impls.rs, branch arti-v0.0.4

tor-circmgr: Remove Arc around ClientCirc

2022-01-07T18:19:20Z

See the new commentary text on `ClientCirc` for the rationale. Signed-off-by: Ian Jackson

De-Arc-ify Buildable for ClientCirc

2022-01-06T20:22:49Z

Remove a bunch of unused RNGs

2021-12-26T02:44:55Z

Allow on-the-fly changing of path_rules

2021-12-07T20:42:14Z

And now the complexity begins: when the user changes the path_rules, they not only want new circuits to obey those rules: they want _all new requests_ to be put onto circuits that obey those rules. That means that when the path rules become more restrictive, we need to retire all the circuits, and make sure that currently pending circuits aren't used for any requests. If it's any comfort, doing this was even more complicated in C tor. ;)

Merge remote-tracking branch 'origin/mr/102'

2021-10-26T17:01:01Z

Overhaul the way WaitFor and the MockSleepProvider work

2021-10-26T15:33:23Z

Instead of racily advancing time forward, this commit attempts to rework how WaitFor works, such that it makes advances when all sleeper futures that have been created have been polled (by handing the MockSleepRuntime a Waker with which to wake up the WaitFor). The above described mechanics work well enough for the double timeout test, but fail in the presence of code that spawns asynchronous / background tasks that must make progress before time is advanced for the test to work properly. In order to deal with these cases, a set of APIs are introduced in order to block time from being advanced until some code has run, and a carveout added in order to permit small advances in time where required. (In some cases, code needed to be hacked up a bit in order to be made properly testable using these APIs; the `MockablePlan` trait included in here is somewhat unfortunate.) This should fix arti#149.

Fix a typo in a comment.

2021-10-25T12:25:59Z

Use better reporting for guard status.

2021-10-13T15:24:37Z

The previous code would report all failures to build a circuit as failures of the guard. But of course that's not right: If we fail to extend to the second or third hop, that might or might not be the guard's fault. Now we use the "pending status" feature of the GuardMonitor type so that an early failure is attributed to the guard, but a later failure is attributed as "Indeterminate". Only a complete circuit is called a success. We use a new "GuardStatusHandle" type here so that we can report the status early if there is a timeout.

WIP

2021-10-11T19:37:59Z

Integrate GuardUsability and GuardMonitor into CircuitBuilder.

2021-10-10T17:48:58Z

(When we're building a path with a guard, we need to tell the guard manager whether the path succeeded, and we need to wait to hear whether the guard is usable.)