mirrors/arti.git/crates/tor-cell/src/relaycell.rs, branch arti-1.2.1

Add and use RelayCellFormatTrait

2024-03-20T14:10:32Z

This lets us paramaterize types and functions by a particular relay cell format. We use this e.g. to statically parameterize the cell crypto functions, thereby removing some run-time branching in the hot path.

RelayCellBody: generalize over RelayCellFormat

2024-03-20T14:07:53Z

Different formats will use different ranges for the `recognized` and `digest` fields.

Remove RelayMsgOuter::decode_from_reader

2024-03-12T15:58:12Z

The semantics of such a function that supports both the legacy V0 format and the V1 packing and fragmentation format are a bit tricky. Since it's not used outside of its module, we can simply remove it.

relay-cell: Update relay cell decoding API for prop340

2024-03-12T15:58:12Z

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 -> UnparsedRelayMsg

2024-03-12T15:58:12Z

For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253

Fix typos

2024-01-08T18:19:11Z

Add deprecated aliases for old RelayCell names

2023-12-14T17:07:20Z

We should remove these once we do our final renaming here, but for now we may as well avoid a breaking change.

Fix documentation that referred to RelayCell.

2023-12-14T17:04:40Z

Fix documentation for {Any}RelayMsgOuter

2023-12-14T16:58:50Z

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.