mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.7 2024-09-03T08:09:02Z 2024-09-03T08:09:02Z Dimitris Apostolou dimitris.apostolou@icloud.com 2024-09-03T08:09:02Z urn:sha1:676f913463b7d84f34dd6101b99d03ef79cf57ad 2024-08-28T14:27:46Z Jim Newsome jnewsome@torproject.org 2024-08-22T19:20:36Z urn:sha1:46f7f01092e6ac55e3e958dc3a2228b1d36e26a1 Having this in the `tor-async-utils` crate prevents us from doing both of the following without introducing a circular dependency: * using it in `tor-rtmock` (which we currently do, particularly in tests). * using `tor-rtmock` to test things in `tor-async-utils`. We don't do this yet, but it is generally sensible to do so. In particular we want to move the `stream_peak` module there, which is currently tested with `tor-rtmock`. Moving this into its own crate avoids this circular dependency. 2024-08-21T21:53:08Z Jim Newsome jnewsome@torproject.org 2024-08-21T21:28:38Z urn:sha1:21ff185c117fda4198a570c4e87cd1a881c44c5f In particular, clarify that stream-flow-control msgs don't get blocked on circuit congestion control. 2024-08-21T18:30:55Z Jim Newsome jnewsome@torproject.org 2024-08-14T20:41:14Z urn:sha1:41cbc63cb172c851f3b58ef0727aa1dfde363bcc * Update `StreamPollSet` to require that its streams implement `PeekableStream`, and to not do its own buffering of values read from the stream. This avoids an extra layer of buffering for streams that already buffer a value, and makes the interior state a little simpler and more robust. It does have a downside of making the API a little less convenient, since the caller must do its own `poll_peek` call if it wants a reference to the item. * Update `StreamMap` to implement `PeekableStream` for `OpenStreamEntStream`, as it must to satisfy the updated `StreamPollSet` API. We have to somewhat constrain the `poll_ready_streams_iter` API to no longer return both a reference to the stream and the message. I don't see a way to return both while satisfying the borrow checker. Luckily we don't really need both anymore. * Update the Circuit reactor to handle the updated `StreamMap::poll_ready_streams_iter` API. 2024-08-15T15:39:23Z Jim Newsome jnewsome@torproject.org 2024-08-15T15:37:31Z urn:sha1:ed099c514dadaeb08506e5916b1c8be261625477 2024-08-13T20:55:14Z Jim Newsome jnewsome@torproject.org 2024-08-13T20:36:21Z urn:sha1:f37260bd5f4e69da85e4e28cadb88cb127cd61cf As clippy points out otherwise, this no longer actually loops. Since the iterator already guarantees that the messages it produces are ready to send with respect to flow control, and we've already validated that we can send with respect to the circuit window, the loop, we can always handle the first item from the iterator. i.e. this changes a `while let` to an `if let`. 2024-08-13T20:54:02Z Jim Newsome jnewsome@torproject.org 2024-08-13T20:25:09Z urn:sha1:86f47616d8e1ed5641796316b1b6e008daa0eda4 This is no longer needed. Removing it shouldn't change any behavior. 2024-08-13T20:52:11Z Jim Newsome jnewsome@torproject.org 2024-08-13T20:10:39Z urn:sha1:bb06a2f9fd2c8683372247ab06e21d0a4919b2ca When we've exhausted circuit-level SENDME window, iterating over streams is likely to be a waste of CPU. Theoretically we might be able to send some messages that don't count towards windows, but on balance it doesn't seem worth it. 2024-08-13T19:46:46Z Jim Newsome jnewsome@torproject.org 2024-08-13T19:16:49Z urn:sha1:4939d2c08a890d97145eceb127c62ecc412f22d5 This prevents us from having to iterate over streams blocked on flow control inside the circuit reactor, and potentially allows further simplification. 2024-08-13T19:46:46Z Jim Newsome jnewsome@torproject.org 2024-08-12T20:49:48Z urn:sha1:4df401ec43b8f1c4e2eff662f1173847718cc3a4 Encapsulate flow-control into a separate object that partially abstracts away the difference between window-based (legacy) flow control and xon-based (prop324) flow control.