Draft: Implement a retry-after-delay mechanism for FallbackDirs
- Mar 25, 2022
-
-
Nick Mathewson authored
-
-
- Mar 23, 2022
-
-
Nick Mathewson authored
(Instead of retrying immediately, wait till at least one will be up.)
-
Nick Mathewson authored
Internally to the circmgr crate, we use a FallbackMonitor object with an API similar to the GuardStatusMonitor. Externally, we have reporting functions to note success and failure. With this change, we now notice when fallbacks have failed or given us useless information, and we mark them as unusable for a while before we consider retrying them. This should be sufficient to solve the problem observed in #406, where some kinds of failures to connect to (or download from) fallback directories resulted in an obnoxious busy-loop.
-
Nick Mathewson authored
This field will track when we can retry, and is now used to see which fallbacks are usable. (It is not yet set on success or failure.) The design here is a bit tricky; I've been through a few iterations of it, and this is the one that seems like it will give us reasonable lifetimes and behavior.
-
Nick Mathewson authored
We're going to want to add some intelligence here, and having an opaque type for this object will help us in the long run.
-
Nick Mathewson authored
This movement will help with #406, which requires that we track the success and failure status of our fallback directories.
-