summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit
Commit message (Collapse)AuthorAgeFilesLines
* Apply deferred rustfmt churnIan Jackson2024-10-091-2/+2
|
* memquota: Introduce type aliases for channel->circuit RX queueIan Jackson2024-10-091-2/+3
| | | | | This is neater and will make changing the type (in a moment) less noisy.
* memquota: impl HasMemoryCost for ClientCircChanMsgIan Jackson2024-10-091-1/+4
| | | | We'll need this in a moment.
* tor-proto: Make incoming stream requests participate in memquotaIan Jackson2024-10-031-2/+2
|
* tor-proto: Implement HasMemoryCost for StreamReqInfoIan Jackson2024-10-031-1/+8
| | | | | This is necessarily a bit fudged, since a StreamReqInfo is full of exciting things like ends of other MPSC queues.
* tor-proto: Make stream queues participate in memquotaIan Jackson2024-10-031-2/+6
| | | | Change the typss of StreamMpscSender and StreamMpscReceiver.
* tor-proto: Put a StreamAccount in DataStream etc.Ian Jackson2024-10-031-1/+6
|
* tor-proto: Put a CircuitAccount in ClientCirc and circuit::ReactorIan Jackson2024-10-031-0/+6
|
* Merge branch 'mpsc-types' into 'main'Ian Jackson2024-10-022-17/+23
|\ | | | | | | | | tor-proto: Introduce type aliases for some queues See merge request tpo/core/arti!2484
| * tor-proto: Introduce type alias for StreamReqSenderIan Jackson2024-10-021-2/+6
| | | | | | | | This will make it a little easier to change the type later.
| * tor-proto: Introduce type aliases for stream queuesIan Jackson2024-10-022-15/+17
| | | | | | | | This will make it easier to change their types.
* | tor-proto: Use trait methods for try_send and channel_close (fmt)Ian Jackson2024-10-011-10/+7
| |
* | tor-proto: Use trait methods for try_send and channel_closeIan Jackson2024-10-011-4/+5
|/ | | | This prepares us to change the types of these queues.
* Fix typosDimitris Apostolou2024-09-031-1/+1
|
* Move stream_peek into tor-async-utilsJim Newsome2024-08-291-2/+2
|
* 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/+6
| | | | | From <https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2340#note_3062531>
* Circuit reactor: improve code commentsJim Newsome2024-08-211-3/+11
| | | | | In particular, clarify that stream-flow-control msgs don't get blocked on circuit congestion control.
* StreamPollSet: disallow polling ready streamsJim Newsome2024-08-211-8/+18
|
* StreamMap: Use StreamUnobtrusivePeeker instead of PeekableJim Newsome2024-08-211-4/+5
|
* tor-proto: Use PeekableStream to get rid of redundant bufferingJim Newsome2024-08-212-55/+86
| | | | | | | | | | | | | | | | | | | | | | | | | * Update `StreamPollSet` to require that its streams implement `PeekableStream`, and to not do its own buffering of values read from the stream. This avoids an extra layer of buffering for streams that already buffer a value, and makes the interior state a little simpler and more robust. It does have a downside of making the API a little less convenient, since the caller must do its own `poll_peek` call if it wants a reference to the item. * Update `StreamMap` to implement `PeekableStream` for `OpenStreamEntStream`, as it must to satisfy the updated `StreamPollSet` API. We have to somewhat constrain the `poll_ready_streams_iter` API to no longer return both a reference to the stream and the message. I don't see a way to return both while satisfying the borrow checker. Luckily we don't really need both anymore. * Update the Circuit reactor to handle the updated `StreamMap::poll_ready_streams_iter` API.
* Circuit reactor: Update comments about outbound message handlingJim Newsome2024-08-151-3/+7
|
* Circuit reactor: remove `'hop_streams` loopJim Newsome2024-08-131-33/+24
| | | | | | | | | | As clippy points out otherwise, this no longer actually loops. Since the iterator already guarantees that the messages it produces are ready to send with respect to flow control, and we've already validated that we can send with respect to the circuit window, the loop, we can always handle the first item from the iterator. i.e. this changes a `while let` to an `if let`.
* Circuit reactor: remove `'outer` loopJim Newsome2024-08-131-55/+50
| | | | This is no longer needed. Removing it shouldn't change any behavior.
* Circuit reactor: don't process streams when we don't have circuit windowJim Newsome2024-08-131-18/+11
| | | | | | | When we've exhausted circuit-level SENDME window, iterating over streams is likely to be a waste of CPU. Theoretically we might be able to send some messages that don't count towards windows, but on balance it doesn't seem worth it.
* StreamMap: apply stream flow control before making messages availableJim Newsome2024-08-132-17/+83
| | | | | | This prevents us from having to iterate over streams blocked on flow control inside the circuit reactor, and potentially allows further simplification.
* tor-proto: Encapsulate flow-controlJim Newsome2024-08-133-59/+54
| | | | | | 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.
* Circuit reactor: remove unnecessary circ window precheckJim Newsome2024-08-131-21/+0
| | | | | | | | | Since we no longer have an outbound queue for each hop, and instead return an error here if there is insufficient circuit window to send a message, there's no need to pre-check whether we have sufficient window. If there's insufficient circuit window, we'll still return an error slightly later, after failing to take from the circuit window.
* StreamMap: rm stray commentJim Newsome2024-08-131-3/+0
|
* Merge branch 'streampollset-no-v' into 'main'David Goulet2024-08-131-1/+1
|\ | | | | | | | | StreamPollSet: remove redundant type parameter V See merge request tpo/core/arti!2334
| * StreamPollSet: remove redundant type parameter VJim Newsome2024-08-121-1/+1
| | | | | | | | | | This was required to be the same type as `S::Item`. We can just use `S::Item` directly.
* | tor-proto: removed CountedHashMapJim Newsome2024-08-122-542/+0
|/ | | | | | | | | | | This was written for use in StreamMap, with an eye towards potentially reusing it elsewhere. We no longer use it in StreamMap, so it's currently unused. Probably best to go ahead and remove it now and resurrect it if we decide we want it later than to maintain dead code (or to make it more widely available without more concrete use-cases).
* StreamMap: Merge rxs into open_streamsJim Newsome2024-08-081-72/+63
| | | | | | This simplifies the bookkeeping a bit, and clears a path towards updating the Streams in our StreamPollSet to directly respect flow control.
* StreamMap: Put open streams in their own map instead of CountedHashMapJim Newsome2024-08-082-137/+124
| | | | | | This temporarily results in *more* bookkeeping, but is a step towards putting the mpsc receivers back into `OpenStreamEnt`, and putting the whole `OpenStreamEnt`s into the `StreamPollSet`.
* StreamMap: test n_open_streamsJim Newsome2024-08-081-1/+13
|
* StreamPollSet: allow access to inner streamsJim Newsome2024-08-081-9/+11
|
* tor-proto streammap: Drop receiver for outgoing messages after ENDJim Newsome2024-08-061-0/+4
| | | | Fixes #1513
* tor-proto: add Debug impls and improve panic messageJim Newsome2024-08-063-2/+8
| | | | For debugging #1513
* tor-proto: Remove circuit reactor's outbound bufferJim Newsome2024-08-011-71/+13
| | | | | | | We no longer need this. StreamMap now supports handling only one outgoing message at a time while ensuring no streams starve, so we no longer ever pull messages out of the map when we're not actually ready to send them.
* tor-proto::circuit::StreamMap: Use StreamPollSetJim Newsome2024-08-013-75/+128
| | | | | | | | | | | | | | | | | | | | * Refactors `StreamMap` to use `StreamPollSet` to manage its receivers for mpsc streams. * Extends `StreamMap` to support iterating only over streams that have a pending outgoing message, and in round-robin order. * Updates `circuit::reactor::Reactor` to use this functionality. It now iterates only over streams that have a ready outgoing message, and only actually "pops" a message that is ready to be sent. This mildly simplifies the circuit reactor, but more importantly clears the way to: * Remove the "outbound queue" of messages that were pulled from stream channels but that we couldn't send yet due to congestion control. * Support opportunistic packing when preparing to send a relay message. (proposal 340). * Refactor the circuit reactor's `run_once` into futures that we can `select!` over.
* circuit reactor: add comment pointing to tests in other moduleJim Newsome2024-07-291-1/+3
|
* Fix two TODO ticket numbersIan Jackson2024-06-251-1/+1
| | | | | I seem to have mistyped this ticket number. We meant #1397 aka "Circuit reactor isn't great", not some release ticket.
* Merge branch 'sometimes-unbounded' into 'main'Nick Mathewson2024-06-111-50/+13
|\ | | | | | | | | RFC: Provide and use SometimesUnboundedSender in circuit reactor See merge request tpo/core/arti!2172
| * Use SometimesUnboundedSink for the circuit reactor's bag-on-the-sideIan Jackson2024-05-291-50/+13
| |
* | Merge branch 'poll-ready-unpin-bool' into 'main'Nick Mathewson2024-05-291-3/+4
|\| | | | | | | | | Tidy up the ChannelSender::poll_ready inherent method See merge request tpo/core/arti!2171
| * ChannelSender::poll_ready_unpin_bool: move to utilIan Jackson2024-05-291-1/+1
| | | | | | | | This is where it belongs.
| * ChannelSender::poll_ready_unpin_bool: extension traitIan Jackson2024-05-291-0/+1
| | | | | | | | | | | | | | This makes this available for any Sink + Unpin. Which we want because we're about to wrap our ChannelSender in a Sink wrapper. It's in the wrong place now; we'll move it in a moment.
| * ChannelSender::poll_ready_unpin_bool: rename from poll_readyIan Jackson2024-05-291-3/+3
| | | | | | | | | | | | | | | | | | | | This would otherwise shadow the poll_ready method, which is confusing. Also this paves the way for making it available for any Sink + Unpin. Improve the docs somewhat to explain what this thing actually is.
* | proto: Make DataWriter::close actually do something.Nick Mathewson2024-05-291-2/+6
|/ | | | | | | | | | | | | | | | | | | 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: Make Channel explicitly Arc<.>Nick Mathewson2024-05-161-2/+2
| | | | | | | | | | | | | | | | Previously, Channel was a type that you could Clone that implicitly its state. Now, Channel always appears as an Arc<Channel>. This change has several benefits: * It makes the relationship between Channel struct and the underlying channel more clear. * It enables Channel to participate in the RPC system, where everything has to be an Arc<.> * It enables us to have a Weak<Channel>, if we ever want to. * It will let us move various members out of ChannelDetails. We did this change a while ago with ClientCirc.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 04:55:20 +0000