mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.6 2025-06-26T17:03:13Z 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. 2024-10-22T12:19:22Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-22T12:19:15Z urn:sha1:905dad6dd31a4927c8d35b081105d69e1063cf77 2024-10-22T12:19:22Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-22T12:16:26Z urn:sha1:eed28245887b87a7bf1e884b568f8062148cdd76 Promote the associated comments. As suggested here: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2560#note_3097188 2024-10-21T10:11:20Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-16T15:25:28Z urn:sha1:a67433aa9a0a079d1e070d40000fdb74fb6bbc06 We need the mq account for the stream not to collapse. The ResolveStream object needs to contain a strong reference to it. Have begin_stream_impl return the StreamAccount, rather than taking it as a parameter. That makes this bug a little more obvious. It also centralises the StreamAccount creation. 2024-03-12T15:58:12Z Jim Newsome jnewsome@torproject.org 2024-03-04T17:17:41Z urn:sha1:190d1cba722c1ebe840eca2b06d82a89678847dc For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253 2023-02-27T13:14:15Z Nick Mathewson nickm@torproject.org 2023-02-27T13:14:15Z urn:sha1:07473ed1fc110b8b48ef02bb288b1f50085dfa06 2023-02-17T16:50:27Z Nick Mathewson nickm@torproject.org 2023-02-17T16:50:27Z urn:sha1:c5be3c089efc75453762ea975a9a96e6560057dc The role of CmdChecker is to verify that messages are arriving at the appropriate sequence on a stream, with respect to the other messages that have been received. Once the stream becomes half-closed, the CmdChecker is also in charge of consuming incoming messages on the stream and making sure that they are well-formed. 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.