summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src/relaycell.rs
Commit message (Collapse)AuthorAgeFilesLines
* tor-cell: add pub `PAYLOAD_MAX_SIZE_{ALL,ANY}`Steven Engler2025-09-151-0/+50
|
* padding: Report when we have received padding or data.Nick Mathewson2025-09-021-0/+11
| | | | (This was so much easier than reporting on the send side.)
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-071-4/+4
| | | | | | | | | | | | | | First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.
* tor-cell: change `UnparsedRelayMsg::data_len`Steven Engler2025-07-151-6/+32
| | | | | | | | | It now performs some validation and can return a `Result`. We perform validation here since different cell formats may have different maximum data lengths in the future, and `UnparsedRelayMsg` doesn't expose the cell format so it's difficult to perform this validation at a higher layer.
* tor-cell: remove `flowctl-cc` feature and make XON/XOFF cells stableSteven Engler2025-07-151-1/+0
| | | | | I don't see any further changes being needed for these types, and it simplifies a lot of future code in tor-proto that uses these types.
* tor-cell: fix incorrect XON/XOFF cell command integersSteven Engler2025-06-231-5/+5
|
* tor-cell: add `Xon`/`Xoff` cellsSteven Engler2025-06-091-1/+10
|
* cell: move ExtList module out of hs module.Nick Mathewson2025-05-071-0/+1
| | | | We're going to use it for ntorv3 extensions as well.
* proto, cell: Remove RelayCellFormatTrait.Nick Mathewson2025-05-061-51/+0
| | | | | | | | | | | | | | | | The purpose of the trait was to parameterize the tor1 cell crypto on the different possible relay cell layouts. It made sense to have this trait when we thought we would implement the new cell layout for prop340 (packed-and-fragmented) well before we implemented CGO. But it now appears all but certain that CGO will land long before we make any more headway on prop340. Therefore, it doesn't make sense to carry the ability to customize `tor1` for other relay cell layouts. Removing this trait saves a fair bit of complexity.
* tor-cell: optimize slice indexingSteven Engler2025-04-301-2/+2
|
* tor-cell: rename `STREAM_ID_OFFSET` to `STREAM_ID_OFFSET_V0`Steven Engler2025-04-301-3/+3
|
* tor-cell: add `UnparsedRelayMsg::data_len`Steven Engler2025-04-301-1/+21
|
* cell: simpler (?) approach to StreamIdReqNick Mathewson2025-04-161-22/+43
| | | | | | Instead of having a StreamIdReq that indicates "None in V1, Any in V0", take an optional RelayCellFormat as an argument.
* cell: simpler approach to assert-checking offsetsNick Mathewson2025-04-161-5/+5
|
* cell: Implement parsing and encoding for V1 relay cellsNick Mathewson2025-04-161-14/+130
| | | | This is the main part of #1944, and will be needed for CGO.
* cell: Add a debugging-only method to simplify debug_asserts.Nick Mathewson2025-04-161-12/+3
|
* cell: Refine StreamIdReq for V1 relay cells, with minimal changesNick Mathewson2025-04-161-8/+14
| | | | | | | | | | Fortunately, the type is crate-internal, so this is not a breaking change. The key insight with this change is that, from the _caller's_ POV, the set of cells that are allowed to have StreamIDs has not changed. The only difference is that the V1 relay cell code needs to distinguish unrecognized commands from the SENDME case.
* cell: Create an unimplemented RelayCellFormat::V1Nick Mathewson2025-04-161-10/+30
|
* Add a RelayCellFormat argument to encode().Nick Mathewson2025-04-161-6/+10
| | | | | | | | | This will let us actually _send_ messages in the right format. This approach is not ideal for packed/fragmented messages; they will need a separate RelayCellEncoder. part of #1944.
* Note some places where we need updates for #1944.Nick Mathewson2025-04-161-0/+16
| | | | (Also note a couple of other CGO-related issues)
* tor-cell: Add encodable conflux relay message types.Gabriela Moldovan2025-02-181-0/+2
| | | | | | | This adds support for encoding and decoding `RELAY_CONFLUX_LINK`, `RELAY_CONFLUX_LINKED`, and `RELAY_CONFLUX_SWITCH` cells. Closes #1852
* tor-cell: Add conflux RelayCmds.Gabriela Moldovan2025-02-181-0/+13
| | | | Part of #1852
* Some HasMemoryCost impls in tor-cellIan Jackson2024-10-021-3/+10
|
* tor-bytes: Only report Truncated for errors at the outer levelIan Jackson2024-09-111-3/+1
| | | | | | | | | | | This is item 1 from https://gitlab.torproject.org/tpo/core/arti/-/issues/1614#note_3074562 and the alternative to item 2 presented in the 2nd half of https://gitlab.torproject.org/tpo/core/arti/-/issues/1614#note_3074648 (Item 3 was done earlier, but now we change the behaviour.) Fixes #1614.
* tor-bytes: Error: provide and call Error::incomplete_errorIan Jackson2024-09-111-0/+1
| | | | | | | | | | | | | | | | | | | We introduce the new constructor and call it at the error generation sites. But there is still not yet any functional change. Change the type of Truncated's field to be Sensitive. The original reason for not doing this no longer applies, since we don't generally want to open-code construction of this variant. Conveniently, changing the type means we get to find all the sites where one *is* constructed and adjust them. In reader.rs and tor-proto we can just call incomplete_error. In tor-cell, there's a call site where we previously provided an underestimate, and where the Reader isn't available. We adjust that ad-hoc but this is fine because the error variant will change. (relaycell is using a Reader from from_slice.)
* tor-bytes: Add a deficit field to Error::TruncatedIan Jackson2024-09-101-1/+2
| | | | This will allow us to fix #1592, but it doesn't do so yet.
* tor-proto::circuit::StreamMap: Use StreamPollSetJim Newsome2024-08-011-1/+1
| | | | | | | | | | | | | | | | | | | | * 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.
* Fix clippy::doc_lazy_continuationIan Jackson2024-07-081-4/+4
|
* Use uXX::MAX in place of std::uXX::MAXNick Mathewson2024-04-221-1/+1
| | | | | | The old code produced a warning from clippy nightly; we may as well update to use the new associated consts. (They've been there since Rust 1.4x.)
* Fix compilation for relaymsg fuzzerNick Mathewson2024-04-021-0/+2
| | | | This broke when we changed the relaymsg api.
* Add and use RelayCellFormatTraitJim Newsome2024-03-201-24/+39
| | | | | | 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 RelayCellFormatJim Newsome2024-03-201-0/+26
| | | | | Different formats will use different ranges for the `recognized` and `digest` fields.
* Remove RelayMsgOuter::decode_from_readerJim Newsome2024-03-121-11/+3
| | | | | | 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 prop340Jim Newsome2024-03-121-23/+225
| | | | | | | | | | | 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 -> UnparsedRelayMsgJim Newsome2024-03-121-7/+4
| | | | | For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
* Fix typosDimitris Apostolou2024-01-081-1/+1
|
* Add deprecated aliases for old RelayCell namesNick Mathewson2023-12-141-0/+8
| | | | | 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.Nick Mathewson2023-12-141-9/+4
|
* Fix documentation for {Any}RelayMsgOuterNick Mathewson2023-12-141-3/+7
|
* Rename {Any}RelayCell to {Any}RelayMsgOuterNick Mathewson2023-12-141-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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<StreamId>` 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.
* Convert StreamId to NonZeroU16Jim Newsome2023-10-251-36/+48
|
* Lower and downgrade a TODO about StreamID and NonZeroU16.Nick Mathewson2023-10-121-1/+6
|
* cell: Downgrade a couple more TODO HS comments.Nick Mathewson2023-06-131-1/+1
|
* cell: Remove relaycell::restrictNick Mathewson2023-06-131-1/+0
| | | | | This module didn't have anything in it; nonetheless, removing it does count as an API break since it was public.
* tor-cell: remove use of arrayrefNick Mathewson2023-06-011-3/+9
| | | | Closes #872
* Change several cfgs to refer to new feature names.Nick Mathewson2023-02-281-1/+1
|
* Rename onion-* cargo features to hs-* in tor-* cratesIan Jackson2023-02-281-1/+1
| | | | Fixes #756
* Merge branch 'hs-cells-1' into 'main'Nick Mathewson2023-02-161-2/+2
|\ | | | | | | | | Start refactoring hs cell implementations See merge request tpo/core/arti!1020
| * tor-cell: rename onion_service module to hsNick Mathewson2023-02-151-2/+2
| |
* | tor-cell: Add another debug_assert to relay cell encodingNick Mathewson2023-02-151-3/+6
| |