mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.1.0 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 2022-02-15T14:41:10Z Nick Mathewson nickm@torproject.org 2022-02-11T17:17:11Z urn:sha1:da0e9e456c398d33c476db5a28e1c6fff5320c4d Additionally, refactor the IoError out of tor_cell::Error: nothing in TorCell created this; it was only used by tor_proto. This required refactoring in tor_proto to use a new error type. Here I decided to use a new CodecError for now, though we may refactor that away soon too. 2022-02-08T23:28:45Z Yuan Lyu lyuyuan92@gmail.com 2022-02-08T23:28:45Z urn:sha1:595fe1ab881b94106649f9b19eebedf926d68f1b 2022-02-05T03:52:51Z Yuan Lyu lyuyuan92@gmail.com 2022-02-04T04:36:01Z urn:sha1:f6f732a47818f789db76ad692d0025de1051072f 2022-01-13T13:12:29Z Ian Jackson iwj@torproject.org 2022-01-13T13:12:29Z urn:sha1:9b723cba53852ecd3505c0cabc42ca3b5d31ad34 2021-11-25T13:20:37Z Daniel Eades danieleades@hotmail.com 2021-11-25T13:14:05Z urn:sha1:db16d13df4779ac61005050dfe5ce05e3d5a1b5d 2021-11-15T17:57:01Z Nick Mathewson nickm@torproject.org 2021-11-15T17:55:08Z urn:sha1:f92ad644c90480cd6ea738201119ce1e9fd40d8e Closes #222. 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-11-03T16:48:54Z eta tor@eta.st 2021-11-03T16:34:33Z urn:sha1:db6b91164ec1069025b7b600f667220b33309b45 @nickm pointed out that refactoring tor_proto::channel's Reactor to do sending as well meant that it could only send or receive, but not both, simultaneously, which was bad! To fix this, rewrite Reactor::run_once to use a handcrafted future (with futures::future::poll_fn) that can handle the logic required to push items onto the sink asynchronously (i.e. checking that it can be written to before trying to do that, and then flushing it). This also means we don't use select_biased! any more, and just handroll that logic ourselves; as a small bonus, we can now process all 3 kinds of message in one run_once() call, instead of having to do only one of them.