mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.2 2021-11-24T23:12:44Z 2021-11-24T23:12:44Z Nick Mathewson nickm@torproject.org 2021-11-24T22:31:42Z urn:sha1:f55950ab8d86fec3c5fbe33650c4a7001f9812b3 Also fix some commonwealth spellings that had slipped in. 2021-11-02T19:32:44Z Nick Mathewson nickm@torproject.org 2021-11-02T19:32:44Z urn:sha1:b0265c490e35ec7bd6c6a837e79c92a9790717d7 2021-11-02T18:17:18Z Nick Mathewson nickm@torproject.org 2021-11-02T18:17:18Z urn:sha1:78fbb141be5ac3c51c1a8e44f7f4b50da9d713cd 2021-11-02T16:17:11Z Nick Mathewson nickm@torproject.org 2021-11-01T20:06:41Z urn:sha1:876a569f6cdda44600263cc4f9553987d2022d92 We define "coming back online" as happening when a guard attempt succeeds, if that attempt that was launched when we seemed to be offline. We define "seeming to be offline" as having all of our primary guards marked unreachable, and having received no incoming network traffic in a while. Closes #216. 2021-11-02T15:19:57Z Nick Mathewson nickm@torproject.org 2021-11-02T15:19:57Z urn:sha1:453855693b1d53a26fa8315f6d29a97b04cf8485 This is based on @eta's patches for !118 and !119: Since we already have an unbounded channel, we don't need to use an elaborate mess of one-shot senders. We can just use the unbounded_send() method, which also lets us enqueue a message without having to await. Closes #219. 2021-10-29T12:39:04Z Nick Mathewson nickm@torproject.org 2021-10-29T12:39:04Z urn:sha1:1ee24ce6537373448d8fd5fb074768c6887cb90b 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). 2021-10-26T16:03:23Z Nick Mathewson nickm@torproject.org 2021-10-25T15:45:37Z urn:sha1:72ebaed16bc5c4e79c29fe135b62b28f945bdcd0 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. 2021-10-19T20:21:12Z Nick Mathewson nickm@torproject.org 2021-10-19T20:21:12Z urn:sha1:445ec6d22053d3f76534844b6c02aefa1fbaedd7 (One represents code that I forgot to write.) 2021-10-13T15:24:37Z Nick Mathewson nickm@torproject.org 2021-10-13T15:24:37Z urn:sha1:f15cde80de0b5f6f81a7426addba35c3c7506112 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. 2021-10-13T14:55:44Z Nick Mathewson nickm@torproject.org 2021-10-13T14:55:44Z urn:sha1:e625b2cff5f3f1c04ecaa026c46c0ea82e824b1a