mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=derive-traits 2022-02-15T14:57:03Z 2022-02-15T14:57:03Z Nick Mathewson nickm@torproject.org 2022-02-15T14:57:03Z urn:sha1:6b611d6deae2e003ea81f459cd5e005c37ab50ce 2022-02-15T14:41:11Z Nick Mathewson nickm@torproject.org 2022-02-11T20:20:50Z urn:sha1:f23f375e42ef3237f9bbb7b8bfee47ecc9ced4a1 2021-12-16T16:48:39Z Nick Mathewson nickm@torproject.org 2021-12-16T16:48:39Z urn:sha1:51c4ca73f265558df6ae0c6766a02b228b8404be Previously we'd always set it to true, allowing one CONNECTED per half-closed stream even if the stream had already received a CONNECTED cell. This resolves an XXXX. 2021-12-16T16:33:50Z Nick Mathewson nickm@torproject.org 2021-12-16T16:33:50Z urn:sha1:a09fbc9f271ce6ec474126db4415f7515bfd2b13 2021-12-14T16:37:56Z eta tor@eta.st 2021-12-14T15:49:40Z urn:sha1:8d660cbcf1a655769425dd0a303e5446f6cb8542 arti!126 overhauled the `tor-proto` circuit reactor, but left out one very important thing: actually decrementing the SENDME window for streams (not circuits) when we send cells along them. Since the circuit-level SENDME window would often prevent us from running into a problem, this wasn't caught until my benchmarking efforts noticed it (in the form of Tor nodes aborting the circuit for a protocol violation). fixes arti#260 2021-11-12T15:04:27Z eta tor@eta.st 2021-11-11T17:44:50Z urn:sha1:c559754116678866eabe525f5b189b50cc78b5cc Previously, the reactor would use an `UnboundedSender` to send things to the `RawCellStream`, in order that the reactor wouldn't block if you failed to read from the latter. This is bad, though, since it means people can just run us out of memory by sending lots of things. To fix this, we make the new `StreamReader` type (which does the reading parts from `RawCellStream`) keep track of the stream's receive window and issue SENDMEs once *it* has consumed enough data to require it, thus meaning that we shouldn't get sent enough data to fill the channel between reactor and `StreamReader` (and, if we do, that's someone trying to flood us, and we abort the circuit). As hinted to above, the `RawCellStream` was removed and its reading functionalities replaced by `StreamReader`; its writing functionalities are handled by `StreamTarget` anyway, so we just give out one of those for the write end. This now means we don't need any mutexes! note: this commit introduces a known issue, arti#230 2021-11-12T15:04:24Z eta tor@eta.st 2021-11-09T14:05:31Z urn:sha1:197816d14cfb24c8830b938dac7dc3afb6eb6c26 Rather like e8e9699c3c239d6c30f9ad414f15d3bad6ec03fd ("Get rid of tor-proto's ChannelImpl, and use the reactor more instead"), this admittedly rather large commit refactors the way circuits in `tor-proto` work, centralising all of the logic in one large nonblocking reactor which other things send messages into and out of, instead of having a bunch of `-Impl` types that are protected by mutexes. Congestion control becomes a lot simpler with this refactor, since the reactor can manage both stream- and circuit-level congestion control unilaterally without having to share this information with consumers, meaning we can get rid of some locks. The way streams work also changes, in order to facilitate better handling of backpressure / fairness between streams: each stream now has a set of channels to send and receive messages over, instead of sending relay cells directly onto the channel (now, the reactor pulls messages off each stream in each map, and tries to avoid doing so if it won't be able to forward them yet). Additionally, a lot of "close this circuit / stream" messages aren't required any more, since that state is simply indicated by one end of a channel going away. This should make cleanup a lot less brittle. Getting all of this to work involved writing a fair deal of intricate nonblocking code in Reactor::run_once that tries very hard to be mindful of making backpressure work correctly (and congestion control); the old code could get away with having tasks .await on things, but the new reactor can't really do this (as it'd lock the reactor up), so has to do everything in a nonblocking manner. 2021-09-08T15:28:31Z Daniel Eades danieleades@hotmail.com 2021-08-30T07:52:16Z urn:sha1:fb3b8b84b5709ebe8a29051c43b82c4eef85decc 2021-08-27T13:53:09Z Nick Mathewson nickm@torproject.org 2021-08-27T13:53:09Z urn:sha1:557a0ff40b3731d4690767de27010bbeff08777d This will cause some pain for now, but now is really the best time to do this kind of thing.