aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/stream
Commit message (Collapse)AuthorAgeFilesLines
...
* tor-proto: relax XON limitsSteven Engler2025-10-141-3/+13
|
* tor-proto: remove `StreamEndpointType`Steven Engler2025-10-142-23/+6
|
* tor-proto: relax XOFF limitsSteven Engler2025-10-141-22/+30
|
* tor-proto: add derives for `CellCount`Steven Engler2025-10-141-1/+1
|
* proto: Fix flow control docs post-move.Gabriela Moldovan2025-10-071-2/+2
| | | | | | | | | | `StreamFlowCtrl` is no longer accessible via `tor_proto::client`, so I had to update one of the (doc) imports with its new path Also, I had to change a couple of imports to use `DataWriter` and `DataStream` from `crate::client::stream` instead of `crate::client::stream::data`, because the latter is not visible from `flow_ctrl` anymore.
* proto: Move flow_ctrl module under stream (fmt).Gabriela Moldovan2025-10-071-1/+1
|
* proto: Move flow_ctrl module under stream.Gabriela Moldovan2025-10-078-0/+1064
| | | | This will be used by exits too, so I am moving it out of `client`.
* proto: Move the `stream` module under `client` (breaking).Gabriela Moldovan2025-08-1810-2731/+0
| | | | | | | | | | | | 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.
* proto: Rename the `tunnel` module to `client` (fmt).Gabriela Moldovan2025-08-183-3/+3
|
* proto: Rename the `tunnel` module to `client`.Gabriela Moldovan2025-08-187-9/+9
| | | | | | 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.
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-073-5/+5
| | | | | | | | | | | | | | First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.
* tor-proto: make stream recv queues unbounded if "flowctl-cc" enabledSteven Engler2025-08-051-7/+27
|
* conflux: Adjust docs and fix doc links.Gabriela Moldovan2025-08-051-1/+1
|
* proto: Move ClientCirc stream functions to ClientTunnelDavid Goulet2025-08-053-15/+9
| | | | | | | | | | | | | In order to pull this off, some client => tunnel renaming needed to happen including the comments. The send_raw_msg() is an experimental and expert mode method that any tunnel should have access to in order to be able to send whatever message in whatever tunnel type. No behavior changes. Signed-off-by: David Goulet <[email protected]>
* 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`
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 19:30:58 +0000