summaryrefslogtreecommitdiff
path: root/crates/tor-guardmgr/src/pending.rs
Commit message (Collapse)AuthorAgeFilesLines
* Improve some documentation linksNick Mathewson2021-10-291-3/+3
| | | | | | | | | Instead of putting a fully qualified name in the text, in most cases we should just use the short name of the type or function we're referring to. In other words, instead of saying [`crate::module::Foo`], we should typically say [`Foo`](crate::module::Foo).
* Do not blame a guard for failures on non-random circuits.Nick Mathewson2021-10-261-3/+30
| | | | | | | | | We must not apply our new path-bias behavior (where we blame a guard if it gives us too many indeterminate circuit failures) if the path was not chosen at random. If too many random paths fail, we know that's suspicious, since the other relays are a random sample. But if a bunch of user-provided paths fail, that could simply be because the user's chosen exit is down.
* Fix most warnings from nightly.Nick Mathewson2021-10-191-0/+1
| | | | (One represents code that I forgot to write.)
* Use better reporting for guard status.Nick Mathewson2021-10-131-0/+6
| | | | | | | | | | | | | 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.
* Rename GuardStatusMsg, make it public, add an `Indeterminate` case.Nick Mathewson2021-10-131-19/+36
|
* Resolve small issues and XXXX/TODO comments in GuardMgr.Nick Mathewson2021-10-071-1/+5
| | | | | By the time I merge this, most of the comments should have tickets to go with them.
* Tests for top-level GuardMgr.Nick Mathewson2021-10-071-7/+12
| | | | | | | Also, refactor our message handling to be more like the tor_proto reactors. The previous code had a bug where, once the stream of events was exhausted, we wouldn't actually get any more notifications.
* Initial backend implementation for guard node manager.Nick Mathewson2021-10-071-0/+254
There are some missing parts here (like persistence and tests) and some incorrect parts (I am 90% sure that the "exploratory circuit" flag is bogus). Also it is not integrated with the circuit manager code.