summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/stream
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: Renamed `DataReaderState::Ready` to `Open`Steven Engler2025-06-261-9/+12
|
* tor-proto: remove unneeded `DataReaderState::ReadingCell` stateSteven Engler2025-06-261-10/+6
| | | | | Now that we no longer need to store a future, there's no need for this state since we're never pending waiting for a future to complete.
* tor-proto: rework `StreamReceiver` into a `futures::Stream`Steven Engler2025-06-263-75/+121
| | | | | | | | | | | 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.
* Make `StreamTarget::send_sendme` non-asyncSteven Engler2025-06-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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`.
* tor-proto: rename `StreamReader` to `StreamReceiver`Steven Engler2025-06-264-25/+25
| | | | | | | | | | | | | 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.
* tor-proto: use `DynamicRateLimitedWriter` in `DataWriter`Steven Engler2025-06-161-6/+17
| | | | This uses just a placeholder `Empty` stream for config updates.
* tor-proto: improve `TokioAsyncWrite` compat implSteven Engler2025-06-161-10/+6
| | | | | | We want the tokio trait to call into the futures trait, rather than having each trait duplicate the logic of calling into the inner writer. This is less error-prone.
* tor-proto: change `wake_when_bytes_available` to `NonZero<u64>`Steven Engler2025-06-081-1/+2
|
* tor-proto: change `RateLimitedWriter` logic to use user-configurable limitSteven Engler2025-06-051-0/+12
| | | | The user now sets a constant amount of bytes to wait for.
* tor-proto: add `{TokenBucket,RateLimitedWriter}Config` typesSteven Engler2025-06-051-3/+6
|
* tor-proto: add missing doc comment to `DataWriter::writer`Steven Engler2025-06-051-0/+1
|
* tor-proto: pass the time provider to the `DataWriter`Steven Engler2025-06-052-9/+26
|
* tor-proto: update doc comments for `DataWriter{,Inner}`Steven Engler2025-06-051-21/+25
| | | | | Unfortunately the git diff thinks I moved the struct, but I really only moved the comment.
* tor-proto: rename `DataWriter`Steven Engler2025-06-051-14/+32
| | | | | `DataWriter` -> `DataWriterInner` `DataWriterNew` -> `DataWriter`
* tor-proto: add (what will be) the new `DataWriter`Steven Engler2025-06-051-0/+44
|
* tor-proto: add no-op XON/XOFF flow control variantSteven Engler2025-04-231-8/+29
| | | | | | | This doesn't do anything yet, so is effectively like not having stream flow control. This should be implemented as part of arti#534.
* cell, proto: Use correct Data sizes for v1 relay cellsNick Mathewson2025-04-161-13/+25
| | | | | | | | | | | | Since v1 cells have a longer tag, they can fit less data into a single cell. Ah well, that's the cost of improved security. The code in data.rs is a little wonky, in that it currently requires its buffer to be exactly the maximum size for a data cell. We have a TODO about fixing that in the future, but for now I've moved it to use a boxed slice rather than a boxed array. Part of #1944.
* Add a RelayCellFormat argument to encode().Nick Mathewson2025-04-161-1/+1
| | | | | | | | | This will let us actually _send_ messages in the right format. This approach is not ideal for packed/fragmented messages; they will need a separate RelayCellEncoder. part of #1944.
* tor-proto: made `StreamTarget::send_sendme` async and fixed a TODOSteven Engler2025-03-241-1/+1
|
* squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-181-1/+1
| | | | - `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
* Apply 1 suggestion(s) to 1 file(s)Nick Mathewson2025-02-271-1/+1
| | | Co-authored-by: Ian Jackson <[email protected]>
* Make DataStream, and its members, implement Sync.Nick Mathewson2025-02-261-6/+10
| | | | | | | Also, use static_assertions to enforce that that they _stay_ Send+Sync. Closes #1859.
* tor-proto: Add a tunnel module.David Goulet2025-02-206-10/+16
| | | | | | | | | | | | | Move StreamTarget to the tunnel module and the circuit module. From now on streams will be implemented on tunnels, not circuits. This moves `StreamTarget` to the tunnel module. A future change will replace `ClientCirc` with `ClientTunnel` inside `StreamTarget`. This is mostly code motion, best reviewed with `--color-moved`. Signed-off-by: David Goulet <[email protected]>
* tor-proto: Remove deprecated DataStream API.Gabriela Moldovan2025-02-131-32/+0
| | | | | Reducing `ClientCirc` proliferation will make our lives easier when implementing !2790.
* proto: deprecate DataStream::circuitNick Mathewson2025-01-301-0/+4
| | | | | | | | This method is experimental, so no semver note is needed. It is redundant with `client_stream_ctrl()?.circuit()?`. (The name and the unconditional return type of this method are probably an error.)
* proto: Rename (experimental) DataStream functions for ctrl accessNick Mathewson2025-01-301-6/+6
| | | | | Since these return a client-specific type, they need a client-specific name before we can stabilize them for RPC.
* proto: Rename ClientDataStreamCtrl::{is_open=>is_connected}Nick Mathewson2025-01-301-5/+2
| | | | | | | Semantically, the new name matches the behavior much better. (A stream could well count as open if we had sent a RESOLVE but not received a RESOLVED, so we might someday want to have an `is_open` defined for _all_ streams, not just data streams.)
* proto: Rename DataStreamCtrl to ClientDataStreamCtrlNick Mathewson2025-01-301-16/+16
| | | | | | The API for this type, and the fact that it implements ClientStreamCtrl unconditionally, means that it is only for client DataStreams.
* proto: Clarify applicability of ClientStreamCtrl.Nick Mathewson2025-01-301-4/+2
|
* proto: Use congestion control in circuit reactorDavid Goulet2025-01-162-8/+8
| | | | | | | | | | It is official, congestion control is now used at this commit by the circuit reactor making circuit/sendme.rs unused. Will be removed with another commit. Related #534 Signed-off-by: David Goulet <[email protected]>
* memquota: Use _ rather than allow(dead_code) (fmt)Ian Jackson2024-10-221-1/+4
|
* memquota: Use _ rather than allow(dead_code)Ian Jackson2024-10-222-12/+16
| | | | | | | Promote the associated comments. As suggested here: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2560#note_3097188
* memquota: fix data stream account lifetimeIan Jackson2024-10-211-5/+18
| | | | | | | | | The DataStream is sometimes disassembled, eg by split. When that happens, the StreamAccount would be dropped - and that was the only strong reference. Put a StreamAccount in each of the pieces, instead of just in the combined DataStream struct.
* memquota: Fix resolve stream account lifetimeIan Jackson2024-10-211-2/+7
| | | | | | | | | 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.
* tor-proto: Put a StreamAccount in DataStream etc.Ian Jackson2024-10-032-4/+18
|
* tor-proto: Put a StreamAccount in DataStream etc. (pre-fmt)Ian Jackson2024-10-031-2/+9
|
* Some HasMemoryCost impls in tor-protoIan Jackson2024-10-021-1/+4
|
* tor-proto: Introduce type aliases for stream queuesIan Jackson2024-10-021-2/+2
| | | | This will make it easier to change their types.
* extract tor_async_utils::oneshot into ::oneshot-fused-workaroundJim Newsome2024-08-281-1/+1
| | | | | | | | | | | | | | 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.
* flow-control: document idea for making more robustJim Newsome2024-08-211-0/+5
| | | | | From <https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2340#note_3062531>
* tor-proto: Encapsulate flow-controlJim Newsome2024-08-131-0/+75
| | | | | | 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.
* Fix clippy::doc_lazy_continuationIan Jackson2024-07-081-1/+1
|
* proto: Try to clarify why StreamReader has a StreamTarget.Nick Mathewson2024-05-292-3/+10
|
* proto: Improve documentation about DataStream lifetimes and closingNick Mathewson2024-05-291-0/+30
| | | | | | | In particular, clarify that dropping the DataWriter on its own does nothing unless the DataReader is also dropped. Related to #1368.
* proto: Make DataWriter::close actually do something.Nick Mathewson2024-05-291-7/+21
| | | | | | | | | | | | | | | | | | | Previously we had a bug where `<DataWriter as AsyncWrite>::close` (or `shutdown` in tokio-land) would not actually have any effect. It _would_ drop the `StreamTarget` held by the `DataWriter`, but since the `DataReader` also held a `StreamTarget`, the MPSC channel would not get closed, and the circuit reactor would not realize that the stream wanted to shut down. Now we use `mpsc::Sender::close_channel` to make our closes effectual. Closes #1368. Additionally, we fix a bug where `poll_close()` never actually did anything if the buffer had nothing in it when it was called. Previously, `poll_flush_impl()` would exit immediately if it had no data to flush. That isn't what we want when we are closing!
* proto: Explicitly enforce maxima on SENDME windows.Nick Mathewson2024-05-141-1/+1
| | | | | | | | | | | | | | No actual bug here, just technical debt: For `SendWindow`s, our tag system already ensured that we rejected any SENDME that didn't correspond to an appropriate drain. Still, it doesn't hurt to check. For `RecvWindow`s, it would have been a protocol violation if we ever did this, but it makes sense to make it an internal error if we try. Part of #1383.
* proto: Fix compilation with stream-ctrl but not experimental-api.Nick Mathewson2024-05-141-1/+1
|
* proto: Expose wait_for_connection as a part of the DataStream API.Nick Mathewson2024-05-091-1/+1
|
* Rename the old IncomingStreamRequestContext to StreamReqInfo.Nick Mathewson2024-03-261-3/+1
| | | | (Doing this to prevent us having two structs with the same name.)
* Add an IncomingStreamRequestFilter to check early propertiesNick Mathewson2024-03-261-1/+46
| | | | | | | Based on designs in #1124. Note that there is a TODO here about a hack I had to do to appease the borrow checker.