mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.6.0 2025-09-16T16:49:53Z 2025-09-16T16:49:53Z Gabriela Moldovan gabi@torproject.org 2025-09-16T15:06:47Z urn:sha1:b711b628faa530de207c8c20de571e6f138d9455 This enables us to read the CBT estimates from the circuit reactor (we need these to compute the half-stream timeouts for #264). 2025-09-16T16:43:04Z Gabriela Moldovan gabi@torproject.org 2025-09-16T13:58:58Z urn:sha1:63c833d679aefc13bf4f64703fc56c639f5b6ad3 2025-09-15T17:01:31Z David Goulet dgoulet@torproject.org 2025-09-15T17:01:31Z urn:sha1:45a710b088580b4a2c608bcc86c0a8f9b92ea51c tor-proto,tor-netdir: add flow control consensus parameters See merge request tpo/core/arti!3249 2025-09-11T16:15:34Z Steven Engler opara@torproject.org 2025-09-10T22:27:25Z urn:sha1:1e0411c2cd4883e7c73d1d53fc8410a8722f37c9 `Release.md` gives a wildcard path of `crates/*/semver.md`, so it seems that these files should go in the top level of each crate. 2025-08-28T21:28:12Z Nick Mathewson nickm@torproject.org 2025-08-28T21:28:12Z urn:sha1:518a491984cbd7f4239501dbb8a00d57dfc7a195 2025-08-28T10:54:48Z Gabriela Moldovan gabi@torproject.org 2025-08-26T17:48:56Z urn:sha1:4ee5a4abcee895e79588888f6bc8eaa6963a6ba7 This is just code motion (I suggest reviewing with `--color-moved`). This also moves the implementation-agnostic parts from `tor_proto::client::circuit` to a new `tor_proto::circuit` module. 2025-08-18T16:09:04Z Gabriela Moldovan gabi@torproject.org 2025-08-18T15:52:38Z urn:sha1:702e7276898d3f31e22033c5b64fea91703f3701 The `stream` module is client-specific, for the most part, so I am moving it under `client`. Later on, we will factor out the parts that can be shared with the relay implementation. Note: this is a breaking change as the deleted `stream` module was `pub`. We could've kept the module and reexported from it the public types from `tor_proto::client::stream`, but I think it's better to have this `client` namespacing, because it makes the separation between the client and relay parts clearer. 2025-07-08T10:08:20Z Gabriela Moldovan gabi@torproject.org 2025-07-08T10:08:20Z urn:sha1:c5657f1594674c736c3e4198ae2090763ac94ef1 2025-06-26T17:03:13Z Steven Engler opara@torproject.org 2025-06-26T04:45:27Z urn:sha1:3eabc89dc9a1f6be166c2a468785d7708aa3a5bb Having this be a `futures::Stream` makes it nicer to work with. For example we are able to remove a boxed future from `DataReaderState`, which should be better for performance and makes the code simpler. As mentioned in a previous commit when this type was named `StreamReader`, this type is public in the API, but is not actually accessible. As far as I can tell there is no way to construct it or access it. 2025-06-26T17:01:22Z Steven Engler opara@torproject.org 2025-06-26T03:20:38Z urn:sha1:d633fbc26e84b190306998833f5c8a1e10b58e50 In rust, the typical nomenclature is to use "receiver" for channels, and "reader" for byte streams. For example `mpsc::Receiver` for something that returns objects and `AsyncRead` for something that reads bytes. Since we also have a `DataReader` for reading bytes, I think renaming this from `StreamReader` to `StreamReceiver` better describes what it is (it's not a "reader" in the typical `Read`/`AsyncRead` sense). This type is public in the API, but is not actually accessible. As far as I can tell there is no way to construct it or access it.