summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src/relaycell.rs
Commit message (Collapse)AuthorAgeFilesLines
* 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
| |
* | Move slicewriter to tor-cell and make it private.Nick Mathewson2023-02-151-1/+1
| | | | | | | | Also, add some comments about how it is likely to change.
* | tor-cell: Add RelayCell::into_msg.Nick Mathewson2023-02-151-0/+4
| |
* | tor-cell: Add a new UnparsedRelayCellNick Mathewson2023-02-151-0/+46
| | | | | | | | | | | | We'll use this to router relay messages on a circuit to the appropriate stream, and hand them to that stream, without parsing the message until the stream has been determined.
* | tor-cell: Refactor relay cells to copy much lessNick Mathewson2023-02-151-30/+52
|/ | | | | | | | | | | | | We now manipulate raw relay cell bodies as (an alias for) `Box<[u8;509]>` rather than as (an alias for) `[u8;509]`. This enables us to do much less copying. It will become more important soon, as we defer parsing relay cell bodies even longer. Related to #7. We also use SliceWriter to avoid allocating a Vec<> for every relay message we want to encode, and instead encode directly into the cell.
* Change tor_bytes::Error::BadMessage to a Cow.Nick Mathewson2023-02-091-1/+3
| | | | | | | | | | Actually, to avoid making a breaking change, I'm deprecating BadMessage and creating a new InvalidMessage variant that takes a Cow. This way I don't need to track every crate that re-exposes tor_bytes::Error and call this a breaking change in those. Making this change will allow tor_bytes errors to be much more helpful.
* tor-cell: Rename RelayMsg and RelayCell-related types.Nick Mathewson2023-02-071-5/+5
| | | | Thanks to rust-analyzer for making this simple.
* tor-cell: Make Body and MsgClass traits more uniform.Nick Mathewson2023-02-071-1/+1
| | | | | | | | Doing this will make it much easier to implement a macro that generates restricted instances of the Msg types (for #525). The Body change is a breaking change. I don't think anybody else implements Body, but in theory they could.
* tor-cell: Generic "Restricted{Relay,Chan}Cell" types.Nick Mathewson2023-02-071-10/+28
| | | | | | | These are generalizations of RelayCell and ChanCell respectively, that allow using an arbitrary message type in place of the fully general RelayMsg and ChanMsg types. Doing this is a prerequisite for usefully implementing arti#525.
* Sketch a solution for arti#525Nick Mathewson2023-01-061-0/+1
|
* Merge branch 'hs-cells' into 'main'eta2022-07-221-0/+2
|\ | | | | | | | | Implement ESTABLISH_INTRO relay cell See merge request tpo/core/arti!626
| * Implement ESTABLISH_INTRO relay cellYuan Lyu2022-07-181-0/+2
| |
* | tor-cell: Make encoding method signatures fallible.Nick Mathewson2022-07-111-5/+5
|/
* Implement a higher-level API for the ntor v3 handshakeeta2022-07-081-0/+1
| | | | | | | | | | | | | | | | | | | This implements a higher-level API for the ntor v3 handshake, in line with that exposed by the ntor handshake. It does not, however, use the existing `ClientHandshake` trait, due to fundamental differences in the handshakes (namely, that the v3 handshake can include some additional extra extension data). Currently, the higher-level API assumes circuit extension, and copies the (undocumented!) magic verification string from c-tor that indicates this usage. A rudimentary set of functions for serializing and deserializing extensions to be sent with the handshake is also included, implementing the protocol in proposal 332 § A.2. Currently, it only implements the congestion control extensions specified in proposal 324 § 10.3. part of arti#88
* cell: Move UDP to its own module and feature gate itDavid Goulet2022-06-071-4/+9
| | | | | | Related to #463 Signed-off-by: David Goulet <[email protected]>
* cell: Implement CONNECT_UDP cell from prop339David Goulet2022-06-071-1/+11
| | | | | | | | | Decoding and encoding is implemented according to proposal 339 specifications. Related to #463 Signed-off-by: David Goulet <[email protected]>
* tor-cell: provide HasKind.Nick Mathewson2022-02-151-3/+4
| | | | | | | | | Additionally, refactor the IoError out of tor_cell::Error: nothing in TorCell created this; it was only used by tor_proto. This required refactoring in tor_proto to use a new error type. Here I decided to use a new CodecError for now, though we may refactor that away soon too.
* Actually decrement the stream-level SENDME windoweta2021-12-141-0/+4
| | | | | | | | | | | | | arti!126 overhauled the `tor-proto` circuit reactor, but left out one very important thing: actually decrementing the SENDME window for streams (not circuits) when we send cells along them. Since the circuit-level SENDME window would often prevent us from running into a problem, this wasn't caught until my benchmarking efforts noticed it (in the form of Tor nodes aborting the circuit for a protocol violation). fixes arti#260
* Move all crates into a `crates` subdirectory.Nick Mathewson2021-08-271-0/+260
This will cause some pain for now, but now is really the best time to do this kind of thing.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:28:21 +0000