| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
(This was so much easier than reporting on the send side.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
We're going to use it for ntorv3 extensions as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of having a StreamIdReq that indicates
"None in V1, Any in V0", take an optional RelayCellFormat
as an argument.
|
| | |
|
| |
|
|
| |
This is the main part of #1944, and will be needed for CGO.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
(Also note a couple of other CGO-related issues)
|
| |
|
|
|
|
|
| |
This adds support for encoding and decoding `RELAY_CONFLUX_LINK`,
`RELAY_CONFLUX_LINKED`, and `RELAY_CONFLUX_SWITCH` cells.
Closes #1852
|
| |
|
|
| |
Part of #1852
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
| |
This will allow us to fix #1592, but it doesn't do so yet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| | |
|
| |
|
|
|
|
| |
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.)
|
| |
|
|
| |
This broke when we changed the relaymsg api.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Different formats will use different ranges for the `recognized` and
`digest` fields.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
For consistency with the terminology proposed in
https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
|
| | |
|
| |
|
|
|
| |
We should remove these once we do our final renaming here,
but for now we may as well avoid a breaking change.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This module didn't have anything in it; nonetheless, removing it
does count as an API break since it was public.
|
| |
|
|
| |
Closes #872
|
| | |
|
| |
|
|
| |
Fixes #756
|
| |\
| |
| |
| |
| | |
Start refactoring hs cell implementations
See merge request tpo/core/arti!1020
|
| | | |
|
| | | |
|