mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.9.0 2025-11-24T16:47:11Z 2025-11-24T16:47:11Z Gabriela Moldovan gabi@torproject.org 2025-11-12T11:41:51Z urn:sha1:11f04c2f480826b4857c0722da03cfc3e621d437 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-08-18T16:09:04Z Gabriela Moldovan gabi@torproject.org 2025-08-18T15:16:39Z urn:sha1:f91f291c75b61bf29521755f77097cfa1bc8fe58 2025-08-18T16:09:04Z Gabriela Moldovan gabi@torproject.org 2025-08-18T15:14:43Z urn:sha1:1ee26f2168ee2dede8ab993ef57435334e9efabe The implementation from `tunnel` is client-specific, so we are renaming the module accordingly. The more generic parts will be pulled into a separate module in a future commit. 2025-07-17T18:02:07Z Steven Engler opara@torproject.org 2025-07-17T06:59:32Z urn:sha1:14d95aee7878ce28cb7f8af539b2bca287e785fc This will later become `DataReader`. 2025-07-17T18:02:07Z Steven Engler opara@torproject.org 2025-07-17T06:44:01Z urn:sha1:bcb65bfbf5f198654eaee747dd680b99963c96ca 2025-07-16T17:36:43Z Steven Engler opara@torproject.org 2025-07-15T03:38:23Z urn:sha1:9067118cff859a40772462c20fd0bc44a5e8bedc XON/XOFF flow control will want to know how many data bytes are queued on a stream, so the new types track that. 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:03:08Z Steven Engler opara@torproject.org 2025-06-26T04:02:53Z urn:sha1:eed047cbf888dc8f2d02c772e4b9a5154c77a3d4 There are some pros/cons to this change: Pros: 1. The only remaining `await` in `StreamReceiver::recv` is for polling the receiver, which means we can turn the `StreamReceiver` into a `Stream` in a future commit. 2. We won't block the user from receiving messages while we wait for the circuit reactor to receive our SENDME message and send it on the outgoing channel. 3. The `StreamReceiver` doesn't really care if it can't send the SENDME. There isn't anything it can do, the circuit hop can go away for external reasons like a DESTROY message, and we still want to return all queued messages to the user anyways. Cons: 1. If the `StreamReceiver` sends a SENDME request to the circuit reactor, and the circuit reactor fails to send the SENDME, there's no good way for the reactor to communicate this back to the `StreamReceiver`. 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.