mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.1 2022-11-30T18:05:46Z 2022-11-30T18:05:46Z Nick Mathewson nickm@torproject.org 2022-11-30T18:05:46Z urn:sha1:acc2de7b31625c5c9664eca3d699686ae4601c8f 2022-11-30T16:00:31Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-11-30T16:00:31Z urn:sha1:ab74506dc9c0a048f0101e6d802054a383b55cee The comment says // TODO pt-client: It's not clear to me that we really need this method. and empirically, deleting it, and its callee, is fine. 2022-11-29T16:10:26Z Nick Mathewson nickm@torproject.org 2022-11-29T16:10:26Z urn:sha1:4fff9f9dda33ffdbc74694b1c4484bf004a01f3e We were panicking if the PtMgr gave us an error, which isn't so good. 2022-11-28T18:52:21Z eta tor@eta.st 2022-11-28T15:32:56Z urn:sha1:a3c9fc5b1aa9f1072448fdea336f561b71ce1176 This commit makes the `ChanBuilder` type in `tor-chanmgr` usable by consumers outside of that crate, like the doc comment for `ChannelFactory` says you need to be able to do in order to turn your `TransportHelper` into something useful. As part of doing this, the `event_sender` its constructor takes needed to be dealt with, since it was a crate-internal type that came from inside the `ChanMgr`. Enter `BootstrapReporter`: an opaque wrapper around that sender, now provided as an additional argument to `ChannelFactory::connect_via_transport`. You can now construct a `ChanBuilder` outside this crate, and it'll still be able to report its bootstrap status by unwrapping this new type that's threaded through from the `ChanMgr`. (This was a fair deal of manually threading the type through all the layers in this crate!) Note that you cannot implement bootstrap updating using something that isn't `ChanBuilder` yet due to the type being entirely opaque (but, of course, we can figure out exactly what API the reporter should have later, and add that capability in). 2022-11-28T18:52:21Z eta tor@eta.st 2022-11-22T16:24:15Z urn:sha1:3b41c78d6fc5eceac3b45ea9ef1540b72f9b4004 This commit implements `PtMgr`, a pluggable transport manager responsible for keeping track of spawned PTs and spawning them to satisfy client requests on demand. It does this in two parts: the `PtMgr` type exported to the rest of the code, and the background `PtReactor` that actually does the spawning; this design ensures that only one attempt to spawn a PT is active at a time, and will prove useful later for implementing e.g. timeouts. A few changes were necessary to the rest of the code in order to make this all work out. Namely: - `TransportRegistry`'s API didn't make any sense for two reasons: - It wasn't feasible for implementors to implement `ChannelFactory`, since that'd require constructing a `ChanBuilder` (which requires a bootstrap reporting event sender). - Treating the PT manager as a registry is over-general; it's only necessary for it to spawn pluggable transports, so saddling it with other concerns didn't make any sense. - (It's possible to get extensibility for arbitrary user customization by just letting the user swap in a new `ChannelFactory`, anyway.) - Therefore, the `PtMgr` implements the new `AbstractPtMgr` trait, which is far more narrowly focused; this only exists to solve a dependency loop, and is documented as such. - This provides a `TransportHelper` instead of a `ChannelFactory`. 2022-11-23T16:25:15Z Nick Mathewson nickm@torproject.org 2022-11-23T16:25:15Z urn:sha1:3f5699b95a9b74ae0acd3e2fe0ed3bdcd4f2359c 2022-11-23T16:10:34Z Nick Mathewson nickm@torproject.org 2022-11-23T16:03:03Z urn:sha1:74ebc904e37110380d28c4b36a914522761d0e20 2022-11-23T16:10:34Z Nick Mathewson nickm@torproject.org 2022-11-23T16:01:00Z urn:sha1:1249bedbb0d58c9c4f11c0e9bd589ea5587e47f8 2022-11-23T16:10:34Z Nick Mathewson nickm@torproject.org 2022-11-23T15:55:59Z urn:sha1:2fb36f55850aa569dbbdb61a91a7fe4600d2cf3b 2022-11-23T16:10:34Z Nick Mathewson nickm@torproject.org 2022-11-23T15:42:34Z urn:sha1:c04aa9baed34571a9aface8ad79704da4e4754cf