mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.8 2024-09-11T13:19:19Z 2024-09-11T13:19:19Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-11T13:13:08Z urn:sha1:1632c48a5a2f5744970b841628261d6062881dee 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. 2024-09-11T13:19:19Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-11T11:32:08Z urn:sha1:12c2fbe076cfcff8d734b24d6aef243d09c64d15 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.) 2024-09-10T09:10:19Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-05T15:48:39Z urn:sha1:2ae6523dbfc6f3b26ffdc2465f93afab6de3c542 This will allow us to fix #1592, but it doesn't do so yet. 2024-08-01T17:46:45Z Jim Newsome jnewsome@torproject.org 2024-07-24T02:04:04Z urn: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. 2024-07-08T10:36:25Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-07-08T10:31:47Z urn:sha1:c4fe208c7184c020b5418840ebc5f4044c1601c6 2024-04-22T17:00:29Z Nick Mathewson nickm@torproject.org 2024-04-22T17:00:29Z urn: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.) 2024-04-02T16:26:32Z Nick Mathewson nickm@torproject.org 2024-04-02T16:26:32Z urn:sha1:ebd0a506b4c8e11d2dd6acb8f4e4203cef42fb52 This broke when we changed the relaymsg api. 2024-03-20T14:10:32Z Jim Newsome jnewsome@torproject.org 2024-03-19T00:30:12Z urn: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. 2024-03-20T14:07:53Z Jim Newsome jnewsome@torproject.org 2024-03-14T16:52:13Z urn:sha1:86f38c6d785b0adebcc81878719411b6d4648877 Different formats will use different ranges for the `recognized` and `digest` fields. 2024-03-12T15:58:12Z Jim Newsome jnewsome@torproject.org 2024-03-11T20:33:14Z urn: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.