mirrors/arti.git/crates/tor-cell/src/relaycell.rs, branch arti-v1.2.7mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.72024-08-01T17:46:45Ztor-proto::circuit::StreamMap: Use StreamPollSet2024-08-01T17:46:45ZJim Newsomejnewsome@torproject.org2024-07-24T02:04:04Zurn:sha1:5ca9f0c04dc1bc61deb68ced03a375a850cbef5c
* 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_continuation2024-07-08T10:36:25ZIan Jacksonijackson@chiark.greenend.org.uk2024-07-08T10:31:47Zurn:sha1:c4fe208c7184c020b5418840ebc5f4044c1601c6Use uXX::MAX in place of std::uXX::MAX2024-04-22T17:00:29ZNick Mathewsonnickm@torproject.org2024-04-22T17:00:29Zurn:sha1:4a1ad1dc89f6a9f48c84411560c1617d9e487abc
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 fuzzer2024-04-02T16:26:32ZNick Mathewsonnickm@torproject.org2024-04-02T16:26:32Zurn:sha1:ebd0a506b4c8e11d2dd6acb8f4e4203cef42fb52
This broke when we changed the relaymsg api.
Add and use RelayCellFormatTrait2024-03-20T14:10:32ZJim Newsomejnewsome@torproject.org2024-03-19T00:30:12Zurn:sha1:8a91f277bbb9faa263a33d6b270f652a0da98068
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 RelayCellFormat2024-03-20T14:07:53ZJim Newsomejnewsome@torproject.org2024-03-14T16:52:13Zurn:sha1:86f38c6d785b0adebcc81878719411b6d4648877
Different formats will use different ranges for the `recognized` and
`digest` fields.
Remove RelayMsgOuter::decode_from_reader2024-03-12T15:58:12ZJim Newsomejnewsome@torproject.org2024-03-11T20:33:14Zurn:sha1:92f12efe7e76a227bcb363c41d792ed5b8a71e4a
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 prop3402024-03-12T15:58:12ZJim Newsomejnewsome@torproject.org2024-03-05T20:58:01Zurn:sha1:2d427eb93d699e779c608f71a243d581b1027a73
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 -> UnparsedRelayMsg2024-03-12T15:58:12ZJim Newsomejnewsome@torproject.org2024-03-04T17:17:41Zurn:sha1:190d1cba722c1ebe840eca2b06d82a89678847dc
For consistency with the terminology proposed in
https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
Fix typos2024-01-08T18:19:11ZDimitris Apostoloudimitris.apostolou@icloud.com2024-01-04T18:32:22Zurn:sha1:4eb54be0657862f5d56b047c16c08dabde6a7377