mirrors/arti.git/crates/tor-proto/src, branch arti-v1.2.8mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.82024-09-16T15:00:43Ztor-proto: Use Reader::take_all_but().2024-09-16T15:00:43ZNick Mathewsonnickm@torproject.org2024-09-12T12:49:06Zurn:sha1:17927a8c9a13e027961b62b3c787387e8ed6f2e5tor-bytes: Error: provide and call Error::incomplete_error2024-09-11T13:19:19ZIan Jacksonijackson@chiark.greenend.org.uk2024-09-11T11:32:08Zurn: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.)
tor-bytes: Add a deficit field to Error::Truncated (fmt)2024-09-10T09:10:19ZIan Jacksonijackson@chiark.greenend.org.uk2024-09-05T16:04:59Zurn:sha1:3642336ad06998f8eb8228883abc17a04186534dtor-bytes: Add a deficit field to Error::Truncated2024-09-10T09:10:19ZIan Jacksonijackson@chiark.greenend.org.uk2024-09-05T15:48:39Zurn:sha1:2ae6523dbfc6f3b26ffdc2465f93afab6de3c542
This will allow us to fix #1592, but it doesn't do so yet.
Fix typos2024-09-03T08:09:02ZDimitris Apostoloudimitris.apostolou@icloud.com2024-09-03T08:09:02Zurn:sha1:676f913463b7d84f34dd6101b99d03ef79cf57adMove stream_peek into tor-async-utils2024-08-29T14:08:06ZJim Newsomejnewsome@torproject.org2024-08-21T19:23:49Zurn:sha1:2a11886271c41a0e2449c944b2f24db7f243d506extract tor_async_utils::oneshot into ::oneshot-fused-workaround2024-08-28T14:27:46ZJim Newsomejnewsome@torproject.org2024-08-22T19:20:36Zurn: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.
`tor_proto::channel`: update comment to point to `tor-chanmgr`2024-08-27T14:33:11ZJim Newsomejnewsome@torproject.org2024-08-27T14:33:11Zurn:sha1:adada9b92f278cdb0a4a1e1fbdef91d0ec9c4a4d`circuit` docs: delete comment about no flow-control etc2024-08-26T19:53:11ZJim Newsomejnewsome@torproject.org2024-08-26T19:44:43Zurn:sha1:508d67054c282e9aedda4e5d1e700b8b9e5f3da1
There is now (sendme-style) flow control, and some fairness
(via round robin scheduling of streams).
`circuit` docs: delete "one big mutex" limitation2024-08-26T19:36:01ZJim Newsomejnewsome@torproject.org2024-08-26T19:36:01Zurn:sha1:e5918dfdc4f155ab0c973860a9522faa41f2137a
There is a mutex for some of the "mutable state", but the reactor only
needs to lock it when adding a hop. It's not needed "to process a cell"
or when streams send. Probably not worth calling out here.