mirrors/arti.git/crates/tor-proto/src/circuit/reactor.rs, branch arti-v1.1.13

proto: Use log_ratelim to report problems delivering BEGIN messges.

2024-01-17T14:25:56Z

Give an error on duplicate call to allow_stream_requests.

2024-01-17T14:00:34Z

Closes #1190

proto: Close circuit _intentionally_ when Request Sink is dropped.

2024-01-17T13:45:54Z

In theory, it might be better to just un-register the IncomingStreamRequestHandler when the Receiver for the stream requests is dropped. However, there are two reasons not to do so: 1. It's tricky. We never actually poll on the corresponding Sink, so there isn't a place where the Reactor would expect to get a prompt notification of closure. We only find out that the Receiver has been dropped when an attempt to send on the Sink returns an `is_disconnected` error. 2. It's unnecessary. In the Tor protocols, once we have decided to accept incoming stream requests on a circuit, we want to continue to do so until one of the parties closes the circuit. I've documented this in several comments, in case whe want to get fancier in the future. Closes #1188.

proto: Send END when buffer of IncomingRequests is full

2024-01-17T13:16:48Z

Closes #1189.

Convert a TODO HSS about excessive BEGINs to #1189.

2024-01-10T14:53:51Z

proto: Downgrade TODO HSS about HopNum in IncomingStreamRequestComment

2024-01-10T14:29:53Z

These comments are about internal representations and future extensions. Also, add a fail-safe check to make sure that hop_num consistency is enforced.

proto: Downgrade TODO HSS comments about hop lookup

2024-01-10T14:19:42Z

proto: Change some TODO HSS comments to refer to #1188

2024-01-10T14:18:19Z

clippy nightly: For now, locally allow blocks_in_conditions

2024-01-02T15:04:18Z

Filed https://gitlab.torproject.org/tpo/core/arti/-/issues/1176 proposing a final fix.

Rename {Any}RelayCell to {Any}RelayMsgOuter

2023-12-14T16:56:58Z

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