summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src/relaycell.rs
Commit message (Collapse)AuthorAgeFilesLines
* 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-27 04:59:26 +0000