summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/stream
Commit message (Collapse)AuthorAgeFilesLines
* tor-basic-utils: add `assert_val_impl_trait!` macroSteven Engler2025-07-171-2/+5
|
* tor-proto: replace `DataReader`Steven Engler2025-07-172-44/+48
| | | | | | | | | | | | `DataReader` -> `DataReaderInner` `DataReaderNew` -> `DataReader` This means that the `DataReader` now supports XON/XOFF flow control using the `XonXoffReader`. This means that it can receive requests for a new drain rate from the reactor, and can send the new drain rate to the reactor once there is no more stream data queued.
* tor-proto: add `DataReaderNew`Steven Engler2025-07-173-5/+75
| | | | This will later become `DataReader`.
* tor-proto: add `StreamReceiver::is_empty()`Steven Engler2025-07-171-1/+39
|
* tor-proto: add the `XonXoffReader` and connect it to the reactorSteven Engler2025-07-174-3/+191
| | | | | | | | | | | | The idea here is that the reactor builds an `XonXoffReaderCtrl` for the new stream, and the `XonXoffReaderCtrl` can receive notifications from the reactor's `StreamFlowControl`. The `XonXoffReaderCtrl` can be combined with any `AsyncRead` to build a `XonXoffReader`, essentially wrapping the `AsyncRead` with a type that handles XON/XOFF flow control. Essentially, the reactor gives you a type that allows you to add XON/XOFF flow control support to any `AsyncRead`. We will add this `XonXoffReader` to the `DataReader` in a future commit.
* tor-proto: add plumbing for sending XONSteven Engler2025-07-171-1/+34
| | | | | Nothing actually causes an XON to be sent yet. But this adds the code so that anything holding the `StreamTarget` can request to send an XON.
* tor-cell: add `FlowCtrlVersion::V0`Steven Engler2025-07-161-12/+2
|
* tor-proto: send XOFF messages when the queue grows too largeSteven Engler2025-07-162-4/+65
|
* tor-proto: add dedicated types for the incoming stream queueSteven Engler2025-07-163-2/+245
| | | | | XON/XOFF flow control will want to know how many data bytes are queued on a stream, so the new types track that.
* tor-proto: combine some objects into a `StreamComponents`Steven Engler2025-07-151-23/+16
| | | | | | As we continue adding more functionality to streams like flow control, we'll have more objects to pass around. This tries to group them together.
* tor-proto: rename `StreamSendFlowControl` and related changesSteven Engler2025-07-151-20/+20
| | | | | | | | The plan is to use `StreamSendFlowControl` (now `StreamFlowControl`) for both outgoing and incoming directions, so a name change is needed. This also updates some comments, and renames some related struct fields that have the word "send" in them.
* tor-cell: remove `flowctl-cc` feature and make XON/XOFF cells stableSteven Engler2025-07-151-1/+0
| | | | | I don't see any further changes being needed for these types, and it simplifies a lot of future code in tor-proto that uses these types.
* Merge branch 'flow-ctrl' into 'main'opara2025-07-103-57/+200
|\ | | | | | | | | tor-proto: Handle incoming XON/XOFF messages See merge request tpo/core/arti!3054
| * tor-proto: renamed `get_bytes_per_sec()` to `bytes_per_sec()`Steven Engler2025-07-102-2/+2
| |
| * tor-proto: set `XonXoffBased` variant behind "flowctl-cc" featSteven Engler2025-07-071-0/+8
| |
| * tor-proto: finish support for `StreamSendFlowControl` XON/XOFFSteven Engler2025-07-071-7/+4
| |
| * tor-proto: handle XON/XOFF messagesSteven Engler2025-07-072-3/+65
| |
| * tor-proto: establish channel for rate limit updatesSteven Engler2025-07-072-18/+71
| |
| * tor-proto: code movementSteven Engler2025-07-071-33/+33
| | | | | | | | Moves the `DataWriter` impl to immediately after the definition.
| * tor-proto: small `DataWriter` refactoringSteven Engler2025-07-071-25/+35
| |
| * tor-proto: move sendme decoding into `StreamSendFlowControl`Steven Engler2025-07-071-3/+16
| | | | | | | | | | We only want to try to decode it if the circuit is using window-based flow control.
* | tor-proto: fix 0-len buffer bug in `DataReader::poll_read`Steven Engler2025-06-261-2/+3
|/
* 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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 06:18:26 +0000