mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.4 2022-01-11T18:23:58Z 2022-01-11T18:23:58Z Ian Jackson iwj@torproject.org 2022-01-11T18:23:58Z urn:sha1:cfcd3ea6891d53f3c8eaa12dcbec06e664c3973b 2022-01-11T15:16:03Z eta tor@eta.st 2022-01-11T15:16:03Z urn:sha1:41e202a3a4c582dedd2c9c5c5c60369b4a53fae0 This commit addresses multiple problems highlighted by arti#182: - `arti-client` had some types in its public API that weren't accessible without importing another crate (`CfgPath`, `DataReader`, `DataWriter`). This has been fixed. - In addition, the doc comments for `DataReader` and `DataWriter` were cleaned up to be of better quality, now that they're public. - It was impossible to use `arti-client` without also importing `tor-rtcompat`. This is now fixed by the addition of two convenience methods: `TorClient::bootstrap_with_tokio` and `TorClient::bootstrap_with_async_std`. - Potentially controversially: `tor-rtcompat` now returns *concrete* types from methods like `current_runtime`, instead of `impl Runtime`. - This was needed in order to actually be able to name the `TorClient` type that results from using these methods. - This does mean we lose API flexibility, but on balance I think this is a good thing, because the API we *do* have is actually usable... 2021-12-16T15:39:00Z Nick Mathewson nickm@torproject.org 2021-12-16T15:39:00Z urn:sha1:e2dd418c842ee8d1fae0a943212a9060048d7ec5 This was an XXXX before. Now it explains why the behavior is safe for now, but maybe not forever. 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