mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.6 2023-02-15T15:48:19Z 2023-02-15T15:48:19Z Nick Mathewson nickm@torproject.org 2023-02-13T22:48:33Z urn:sha1:41b50b6c56debc1eeb644d65b2738645bf98fce7 This closes #525, and ensures, at last, that we don't parse any message that we wouldn't accept. 2023-02-07T21:03:14Z Nick Mathewson nickm@torproject.org 2023-02-07T14:18:17Z urn:sha1:d63d7926bd5e94f4129dd1a44e696728125a6c4a Thanks to rust-analyzer for making this simple. 2022-02-24T17:49:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-02-24T17:47:42Z urn:sha1:b56115a04fb0ebedae04a5302a04501b83b845a6 My proximate motivation is that tls-api wants its inner streams to be Debug. But in general, I agree with the Rust API Guidelines notion that almost everything should be Debug. I have gone for the "dump all the things" approach. A more nuanced approach would be possible too. 2022-02-15T14:41:47Z Nick Mathewson nickm@torproject.org 2022-02-11T21:27:27Z urn:sha1:4af279b1730a058093b250696beddd0228793b6d This took some refactoring, and gave an opportunity to notice a few error variants that weren't being used, or didn't mean what they said on the tin. 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-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.