mirrors/arti.git/crates/tor-proto/src/tunnel.rs, branch arti-v1.4.6

proto: Take format+crypto settings from HopSettings

2025-07-23T14:58:47Z

Since these will be negotiated (or determined as part of negotiation) they belong in HopSettings.

tor-proto: add the `XonXoffReader` and connect it to the reactor

2025-07-17T18:01:47Z

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 XON

2025-07-17T18:01:47Z

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-proto: adjust `CtrlMsg::SendSendme` and rename

2025-07-15T05:33:24Z

This allows us to extend the command to implement different flow control methods. We could add new command variants for new flow control methods instead, but I think it makes sense to have them be a single command as they will always have a stream ID / hop location in common. This also helps us keep the flow control logic in one place.

tor-proto: added TODOs for making rate limit stream optional

2025-07-10T00:26:23Z

tor-proto: establish channel for rate limit updates

2025-07-07T17:12:05Z

tor-proto: improve documentation for `StreamTarget::send_sendme`

2025-06-26T17:26:49Z

Make `StreamTarget::send_sendme` non-async

2025-06-26T17:03:08Z

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`.

hsservice: Stop using HopNum and use TargetHop

2025-06-26T14:18:30Z

This requires some changes to the tor-proto crate to handle the inbound TargetHop from the HS subsystem and then resolve it into a HopNum for a single circuit. It is expected that this will change again with Conflux to only use HopLocation internally in a Tunnel and then use HopNum into a Circuit. Signed-off-by: David Goulet

hs: Remove the use of HopNum and instead use TargetHop

2025-06-26T14:18:30Z

This is in the spirit of making everything going inbound the tor-proto crate to use a TargetHop. This becomes much easier for the HS subsystem as it only uses the last hop for its conversation and setup. Signed-off-by: David Goulet