mirrors/arti.git/crates/tor-proto/src/circuit, branch arti-v1.2.4

Merge branch 'poll-ready-unpin-bool' into 'main'

2024-05-29T18:05:57Z

Tidy up the ChannelSender::poll_ready inherent method See merge request tpo/core/arti!2171

proto: Make DataWriter::close actually do something.

2024-05-29T11:28:01Z

Previously we had a bug where `::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!

ChannelSender::poll_ready_unpin_bool: move to util

2024-05-29T11:16:19Z

This is where it belongs.

ChannelSender::poll_ready_unpin_bool: extension trait

2024-05-29T11:16:15Z

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_ready

2024-05-29T11:15:53Z

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 Channel explicitly Arc<.>

2024-05-16T16:24:12Z

Previously, Channel was a type that you could Clone that implicitly its state. Now, Channel always appears as an Arc. 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, if we ever want to. * It will let us move various members out of ChannelDetails. We did this change a while ago with ClientCirc.

proto: Move Channel send functionality into a separate type.

2024-05-16T16:24:12Z

This serves three purposes: * It removes the 'send a cell' method from the channel's public API. Nothing outside of tor-proto should have to use this. * It paves the way for giving each circuit a separate handle onto the channel's send functionality. This will eventually let the channel multiplex among circuits more intelligently. * It prepares for the next commit, which will make Channel itself universally Arc<.>ed.

proto: Explicitly enforce maxima on SENDME windows.

2024-05-14T14:36:05Z

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.

Circuit reactor: use refutable let to unnest some code

2024-05-06T14:33:23Z

Circuit reactor: rename 'hop to 'hop_outbound

2024-05-06T14:33:02Z

It was a bit misleading since it doesn't cover all processing for the hop.