mirrors/arti.git/crates/tor-proto/src/stream/incoming.rs, branch arti-v1.4.0 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.0 2024-10-03T14:10:47Z tor-proto: Put a StreamAccount in DataStream etc. 2024-10-03T14:10:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-02T15:42:18Z urn:sha1:7b97ce4ee6d9f7eb42646f870feb7bde42001ad6 Some HasMemoryCost impls in tor-proto 2024-10-02T18:11:26Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-25T16:50:03Z urn:sha1:83fe0a0db66b02e287fdbd96c107781e6f113609 extract tor_async_utils::oneshot into ::oneshot-fused-workaround 2024-08-28T14:27:46Z Jim Newsome jnewsome@torproject.org 2024-08-22T19:20:36Z urn:sha1:46f7f01092e6ac55e3e958dc3a2228b1d36e26a1 Having this in the `tor-async-utils` crate prevents us from doing both of the following without introducing a circular dependency: * using it in `tor-rtmock` (which we currently do, particularly in tests). * using `tor-rtmock` to test things in `tor-async-utils`. We don't do this yet, but it is generally sensible to do so. In particular we want to move the `stream_peak` module there, which is currently tested with `tor-rtmock`. Moving this into its own crate avoids this circular dependency. Fix clippy::doc_lazy_continuation 2024-07-08T10:36:25Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-07-08T10:31:47Z urn:sha1:c4fe208c7184c020b5418840ebc5f4044c1601c6 Rename the old IncomingStreamRequestContext to StreamReqInfo. 2024-03-26T16:55:05Z Nick Mathewson nickm@torproject.org 2024-03-26T12:51:46Z urn:sha1:500f7c562d0b28f3047fc5cee7cce34ee077517c (Doing this to prevent us having two structs with the same name.) Add an IncomingStreamRequestFilter to check early properties 2024-03-26T16:55:05Z Nick Mathewson nickm@torproject.org 2024-03-20T15:39:05Z urn:sha1:25da33c91ccbd3ac266edf871925ee6a341d4729 Based on designs in #1124. Note that there is a TODO here about a hack I had to do to appease the borrow checker. Run maint/add_warning. 2024-03-13T16:30:53Z Nick Mathewson nickm@torproject.org 2024-03-13T16:30:53Z urn:sha1:c0c9bd15d42897825dd0ab3d3b8dd1c17bd6320c relay-cell: Update relay cell decoding API for prop340 2024-03-12T15:58:12Z Jim Newsome jnewsome@torproject.org 2024-03-05T20:58:01Z urn: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 -> UnparsedRelayMsg 2024-03-12T15:58:12Z Jim Newsome jnewsome@torproject.org 2024-03-04T17:17:41Z urn:sha1:190d1cba722c1ebe840eca2b06d82a89678847dc For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253 tor_cell: never construct empty DATA messages. 2024-02-13T14:37:11Z Nick Mathewson nickm@torproject.org 2024-02-13T14:37:11Z urn:sha1:b5c70dad02124549a13e25f62c8073fef4a063fe We never actually constructed these before, but now we enforce it at the API level. Part of #1269.