aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/stream
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* Run maint/add_warning.Nick Mathewson2024-03-131-0/+1
|
* relay-cell: Update relay cell decoding API for prop340Jim Newsome2024-03-121-2/+2
| | | | | | | | | | | Prop 340: https://spec.torproject.org/proposals/340-packed-and-fragmented.html This updates the decoding API to support multiple versions of the relay cell encoding, including the new encoding proposed in prop340 that supports relay message packing and fragmentation. This commit doesn't actually add support for that new encoding yet.
* Rename UnparsedRelayCell -> UnparsedRelayMsgJim Newsome2024-03-125-15/+15
| | | | | For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
* tor_cell: never construct empty DATA messages.Nick Mathewson2024-02-132-11/+11
| | | | | | | We never actually constructed these before, but now we enforce it at the API level. Part of #1269.
* Rename {Any}RelayCell to {Any}RelayMsgOuterNick Mathewson2023-12-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is pure renaming, done automatically with rust-analyzer. Comment fixes and other cleanups will be in the subsequent commits. We're doing this renaming because we need a name for the combination of a `RelayMsg` and an `Option<StreamId>` that we use when we have a `RelayMsg` we intend to route to a given stream or circuit internally. Previously we called this a `RelayCell`, but that name was already somewhat inaccurate, and will become _very_ inaccurate with the arrival of prop340, which breaksthe 1:1 relationship between relay cells and relay messages. (If we didn't do this renaming now, we'd soon be making the relationship between `UnparsedRelayCell`and `RelayCell` many-to-many, which would be ridiculous and confusing.) The `RelayMsgOuter` name is a placeholder: We expect that we'll want to rename this type, and may also want to rename `RelayMsg`, and unify our vocabulary in other areas too. But such a renaming will have to wait for a larger discussion affecting the specifications, so that we can use the same vocabulary everywhere.
* Send less information in onion service BEGIN messagesNick Mathewson2023-11-151-1/+34
| | | | | | | | | While looking for differences, we found that C tor always omits the flags and the hostname from a BEGIN message sent on an onion service circuit. In torspec!179, we specified that behavior. This patch brings arti into conformance. Closes #1077.
* Convert StreamId to NonZeroU16Jim Newsome2023-10-251-1/+1
|
* proto: Revise the behavior of IncomingStream::discard().Nick Mathewson2023-10-191-9/+12
| | | | | | | | | | | | | Because dropping a `StreamTarget` causes the circuit reactor to send an End, the previous do-nothing implementation of `discard()` wasn't sufficient to cause the request to be ignored without sending an End. This commit modifies our "close pending stream" behavior to only optionally send an End message. To avoid confusion, I'm using a new `CloseStreamBehavior` enum rather than an `Option<End>`, since we had previously used `None` in some cases to indicate a default (misc) end message.
* IncomingStream:: flatten IncomingStreamInner.Nick Mathewson2023-10-191-13/+11
|
* IncomingStream: Remove state.Nick Mathewson2023-10-191-67/+4
| | | | | | Now that every state-change function consumes the IncomingStream, there is no longer any reason to keep track of an internal state enum.
* Note a bug in IncomingStream::discard.Nick Mathewson2023-10-191-0/+2
|
* Remove IncomingStreamInner from its Option.Nick Mathewson2023-10-191-34/+7
| | | | | Now that IncomingStream doesn't implement Drop, we can just destructure it.
* Remove impl Drop from IncomingStreamNick Mathewson2023-10-191-11/+4
| | | | | Since dropping a StreamTarget will send an End, we don't need to call reject_internal in this case.
* proto: Make StreamTarget::close() misuse less likely.Nick Mathewson2023-10-171-3/+4
| | | | | | | | | It turns out that we can make `IncomingStream::reject()` consume self, thus making it impossible to hit the double-close error from outside the `tor-proto` crate. Also, we rename `StreamTarget::close()` to `close_pending()` to better reflect its limited applicability.