summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/stream
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'socket-buf-size' into 'main'opara2026-05-211-0/+1
|\ | | | | | | | | | | | | Set socket buffer sizes (`SO_SNDBUF` and `SO_RCVBUF`) for proxy sockets Closes #2500 See merge request tpo/core/arti!3957
| * tor-proto: add note about proxy socket buf sizesSteven Engler2026-05-071-0/+1
| |
* | tor-proto: have `StreamReqInfo` store a `ReactorStreamComponents`Steven Engler2026-05-211-24/+3
| |
* | tor-proto: add a TODO item for XON/XOFF flow controlSteven Engler2026-05-211-0/+3
| |
* | tor-proto: small comment improvementsSteven Engler2026-05-202-1/+3
| |
* | tor-proto: remove unneeded type aliasSteven Engler2026-05-201-5/+2
| |
* | tor-proto: always use a bounded mpsc queue for streamsSteven Engler2026-05-201-22/+14
| | | | | | | | | | | | | | | | | | | | | | | | Whether a stream queue should be bounded or unbounded is a decision that needs to be made at runtime depending on the type of flow control used, not at build-time. Window-based flow control should be bounded and XON/XOFF flow control should be unbounded. If we wanted to support both bounded and unbounded queues, it would take a bunch of boilerplate code to wrap the senders and receivers in enums. Instead we make the queue always bounded, but use a large bound for XON/XOFF flow control.
* | tor-proto: add `FlowCtrlHooks::inbound_queue_max_len()`Steven Engler2026-05-203-1/+35
| |
* | tor-proto: rename `{,Half}StreamFlowCtrlInner` variantsSteven Engler2026-05-201-10/+10
| | | | | | | | The common suffix isn't needed.
* | tor-proto: rename `*FlowCtrl::e` to `inner`Steven Engler2026-05-071-15/+15
| |
* | tor-proto: rename `*FlowCtrlEnum` to `*FlowCtrlInner`Steven Engler2026-05-071-14/+14
| |
* | tor-proto: fix flow control for half-streamsSteven Engler2026-05-072-19/+74
| | | | | | | | | | | | | | | | | | | | This moves the window-based flow control for half-streams out of the `HalfStream` and into the `HalfStreamWindowFlowCtrl` object. Now that it's applied only in `HalfStreamWindowFlowCtrl` and not generally for all half-streams, we no longer apply window-based flow control to half-streams when they're really using xon/xoff-based flow control.
* | tor-proto: add prototype for `HalfStreamFlowCtrl`Steven Engler2026-05-073-4/+124
| | | | | | | | | | This adds the general structure, and we'll fill it in and use it in a following commit.
* | tor-proto: comment change on `StreamFlowCtrl`Steven Engler2026-05-071-1/+6
|/
* tor-proto: handle a div-by-zero case that should never happenSteven Engler2026-04-131-3/+7
| | | | | If this is zero, then it means that the consensus had bad values. But may as well check it anyways.
* tor-proto: fix flow control side channel checksSteven Engler2026-04-131-35/+47
|
* tor-proto: change flow control `bytes_sent_total` to `u64`Steven Engler2026-04-131-9/+9
|
* tor-proto: add more tests for flow controlSteven Engler2026-04-131-0/+16
|
* tor-proto: change an error to `NotConnected`Steven Engler2026-03-291-3/+7
| | | | | Returning `CircuitClosed` isn't right here since the circuit may not have closed.
* Fix typosTobias Stoeckmann2026-03-241-1/+1
| | | | Typos found with codespell
* proto: Remove unfinished sentence from docsGabriela Moldovan2026-02-161-2/+0
|
* proto: Update IncomingStreamRequestFilter docsGabriela Moldovan2026-02-161-2/+3
| | | | | The `CircHopSyncView` is now the view of a hop, not of the whole circuit.
* proto: Rename CircSyncView to CircHopSyncViewGabriela Moldovan2026-02-161-2/+2
| | | | And update the docs
* Apply 1 suggestion(s) to 1 file(s)Nick Mathewson2026-01-271-1/+1
| | | Co-authored-by: carti-it <[email protected]>
* tor-proto: Report CircuitClosed on unexpected stream rx closeNick Mathewson2026-01-221-6/+4
| | | | | | | | | | | | | | | | As near as I can tell, there are only three ways that the sender corresponding to this rx can be dropped: - `StreamMap::terminate` because the stream object itself was dropped. (But see #2323.) - `StreamMap::close_stream` because an END message or similar has been received. (But see #2322.) - The `StreamMap` has been dropped. The first two cases are already handled, and AFAICT the third can only happen when the circuit hop closes. That makes `CircuitClosed` the appropriate error here, not `StreamProto`. Part of a fix for #2304.
* proto: Fix docs post-refactoringGabriela Moldovan2026-01-131-2/+2
|
* proto: Dedupe IncomingStreamRequestHandlerGabriela Moldovan2026-01-121-1/+26
|
* proto: Fix a number of newly broken doc linksGabriela Moldovan2025-11-241-1/+1
|
* proto: Adjust docs to refer to the new location of StreamReceiverGabriela Moldovan2025-11-241-1/+1
| | | | | | While we still re-export StreamReceiver from the client module, I want to avoid importing it from there in the implementation-agnostic modules, just to make it clearer we're not using client-specific types.
* proto: Move StreamComponents to top-level stream modGabriela Moldovan2025-11-241-2/+1
|
* proto: Move raw under top-level stream modGabriela Moldovan2025-11-241-0/+164
|
* proto: Move StreamTarget to stream moduleGabriela Moldovan2025-11-241-1/+1
|
* proto: Move StreamReqInfo to stream moduleGabriela Moldovan2025-11-241-1/+50
|
* proto: Move IncomingStream* types to shared moduleGabriela Moldovan2025-11-241-1/+295
|
* proto: Adjust a comment about a buffer size.Nick Mathewson2025-10-281-3/+3
|
* proto: Move dumb pipes to top-lvl stream moduleGabriela Moldovan2025-10-211-0/+256
|
* proto: Rename data cmd checkers to {Inbound,Outbound}DataCmdCheckerGabriela Moldovan2025-10-161-3/+3
| | | | | | The previous "incoming" terminology was rather ambiguous. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337
* proto: Move IncomingDataCmdChecker to top-level stream module.Gabriela Moldovan2025-10-161-0/+51
| | | | | | | This will be used by relays too (for validating incoming messages on streams). This is just code motion, so it's best reviewed with `--color-moved`.
* proto: Move cmdchecker under top-level stream module.Gabriela Moldovan2025-10-161-0/+55
| | | | | The CmdChecker will be used by relays too, so I am moving it to the shared `stream` module.
* tor-proto: update unit testSteven Engler2025-10-141-27/+24
|
* 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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 07:01:18 +0000