mirrors/arti.git/crates/tor-proto/src/client.rs, branch arti-v1.6.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.6.02025-09-16T12:29:10ZFix several rustdoc links.2025-09-16T12:29:10ZNick Mathewsonnickm@torproject.org2025-09-16T12:29:10Zurn:sha1:1cecc3bb24604dae6610452cd1db629f43d39f4fFix check_doc_features warning.2025-09-16T12:18:59ZNick Mathewsonnickm@torproject.org2025-09-16T12:18:59Zurn:sha1:eda452df8955e36e91300bc18333bafcdf83ecc1proto: Experimental API to install a circuit padder at a hop.2025-09-15T17:54:29ZNick Mathewsonnickm@torproject.org2025-09-11T20:33:55Zurn:sha1:00b2fe75cd6743668c5effe2d39827e6604f66da
For now, we're not going to implement hop negotiation: we're still
waiting to find a set of padding machines that will be useful for
Arti. This API will help facilitate experimentation to find such
padding machines.
These APIs are under a separate feature (`circ-padding-manual`)
to avoid confusing them with the rest of the padding code:
we only want them to be exported when the researcher wants to
manually install circuit padding.
tor-proto: remove a `pub(crate) use` from `client::stream`2025-09-10T04:37:29ZSteven Engleropara@torproject.org2025-09-10T00:55:24Zurn:sha1:0cdf389a1dfec6ee5604004660c5a142356495b2
For internal types, I think it becomes too much of a mess to export
everything through a single module.
tor-proto: reorganize some flow control modules2025-09-10T04:33:37ZSteven Engleropara@torproject.org2025-09-10T00:42:12Zurn:sha1:17ce18f1f530ceb8fd79940773afc86c5dd17461
This is all private (or pub(crate)) code.
proto: Move TunnelId to a separate, shared module.2025-08-28T10:54:48ZGabriela Moldovangabi@torproject.org2025-08-27T13:02:57Zurn:sha1:567c8bd287c5c5a45b602be80c119fd741f9eb3a
The `TunnelId*` types will be reused in the relay reactor (exit relays
need to have the concept of a "tunnel ID" because of conflux).
Now the `relay::reactor` module only has a single import from `client`
(for the `unwrap_or_shutdown` helper, which we should be able to remove
soon). From now, we will avoid importing anything from `client` in the
`relay` module, and instead prefer refactoring the code as needed (to
pull the implementation-agnostic parts outside of `client`).
This commit has no functional changes, just code motion.
proto: Add a circuit module shared between client and relay impls.2025-08-28T10:54:48ZGabriela Moldovangabi@torproject.org2025-08-26T17:48:56Zurn:sha1:4ee5a4abcee895e79588888f6bc8eaa6963a6ba7
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
proto: Move the `stream` module under `client` (fmt).2025-08-18T16:09:04ZGabriela Moldovangabi@torproject.org2025-08-18T15:56:51Zurn:sha1:fc10bb4cae16e0b19f39fd206d4d6f0b334f3f82proto: Move the `stream` module under `client` (breaking).2025-08-18T16:09:04ZGabriela Moldovangabi@torproject.org2025-08-18T15:52:38Zurn:sha1:702e7276898d3f31e22033c5b64fea91703f3701
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
proto: Rename the `tunnel` module to `client` (fmt).2025-08-18T16:09:04ZGabriela Moldovangabi@torproject.org2025-08-18T15:16:39Zurn:sha1:f91f291c75b61bf29521755f77097cfa1bc8fe58