mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.2 2021-11-12T15:04:27Z 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-10T15:33:31Z Nick Mathewson nickm@torproject.org 2021-11-10T15:31:50Z urn:sha1:428b19c1212fa79d1c7778d8b02c8766ff97245c * Make it crate-visible only. * Make it idempotent * Have it be an internal error if it's called at the wrong time. * Simplify the return logic. 2021-11-10T02:36:12Z Yuan Lyu lyuyuan92@gmail.com 2021-11-09T03:42:59Z urn:sha1:7f799c956bde519efdbff3f814f19ac4e7879345 2021-10-29T13:06:06Z eta tor@eta.st 2021-10-29T13:06:06Z urn:sha1:a12fffc66accb0126500280f540b09c0922c1145 Most of the structs in `arti-client` have example code now, to give a clearer idea of how they're used. Annoyingly, a lot of the types exposed in `arti-client` are actually re-exports, which makes documentation a bit harder: example code that references other parts of `arti-client` can't actually be run as a doctest, since the crate it's in is a dependency of `arti-client`. We might be able to fix this in future by doing the documentation in `arti-client` itself, but rustdoc seems to have some weird behaviours there that need to be investigated first (for example, it seems to merge the re-export and original documentation, and also put the re-export documentation on the `impl` block for some reason). For now, though, this commit just writes the docs from the point of view of an `arti-client` consumer, removing notes specific to the crate in which they're defined. It's not ideal, but at least the end user experience is decent. 2021-10-29T00:48:54Z Nick Mathewson nickm@torproject.org 2021-10-29T00:48:54Z urn:sha1:2057142671c4ced0828c85b01dae02b9b1f0b172 2021-10-29T00:21:35Z Nick Mathewson nickm@torproject.org 2021-10-29T00:19:25Z urn:sha1:c8f65e532e136e76eb0de44eeba83aa2c723c994 2021-10-21T18:22:21Z Nick Mathewson nickm@torproject.org 2021-10-21T18:19:34Z urn:sha1:730be38867c82b8d5ca76a569e1b1175ddf75cd4 2021-10-19T19:49:49Z Nick Mathewson nickm@torproject.org 2021-10-19T19:49:49Z urn:sha1:fb2c7cb85a76acb2a80ae467a635ddb52d80a363 This will let callers use the tokio traits on these types too, if they call `split()` on the DataStream. (Tokio also has a `tokio::io::split()` method, but it requires a lock whereas `DataStream::split()` doesn't.) 2021-10-19T19:48:55Z Nick Mathewson nickm@torproject.org 2021-10-19T19:48:55Z urn:sha1:a9a9f70eb9b8ff7ad5506fed60aaadab1b5c3572 2021-10-19T18:59:29Z eta tor@eta.st 2021-10-19T16:26:52Z urn:sha1:ccd1d36e90dac9f282cdb7199d44f89004f0a070 futures::io::AsyncRead (and Write) isn't the same thing as tokio::io::AsyncRead, which is a somewhat annoying misfeature of the Rust async ecosystem (!). To mitigate this somewhat for people trying to use the `DataStream` struct with tokio, implement the tokio versions of the above traits using `tokio-util`'s compat layer, if a crate feature (`tokio`) is enabled.