mirrors/arti.git/crates/tor-chanmgr/src/lib.rs, branch arti-v1.1.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.02022-11-30T16:00:31ZAbolish ChanMgr::set_default_transport2022-11-30T16:00:31ZIan Jacksonijackson@chiark.greenend.org.uk2022-11-30T16:00:31Zurn: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.
Fix ChanMgr APIs for setting PtMgr etc to match what TorClient wants.2022-11-28T22:29:23ZNick Mathewsonnickm@torproject.org2022-11-28T19:40:06Zurn:sha1:3db0e05b39373defed3a83d1f73959c18e502c90tor-chanmgr: Introduce the BootstrapReporter API, publicize ChanBuilder2022-11-28T18:52:21Zetator@eta.st2022-11-28T15:32:56Zurn: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).
ChanMgr: Rename Factory -> CompoundFactory2022-11-23T16:10:34ZNick Mathewsonnickm@torproject.org2022-11-23T16:03:03Zurn:sha1:74ebc904e37110380d28c4b36a914522761d0e20Mark set-default-factory API as experimental.2022-11-23T16:10:34ZNick Mathewsonnickm@torproject.org2022-11-23T15:52:22Zurn:sha1:f8e103bb9483d13bcef2f9ab6bb5be458e85f4b6Make ChannelFactory and AbstractPtMgr require Send+Sync2022-11-23T16:10:34ZNick Mathewsonnickm@torproject.org2022-11-23T15:42:34Zurn:sha1:c04aa9baed34571a9aface8ad79704da4e4754cfChanMgr: Implement functions that replace channel factories.2022-11-23T16:10:34ZNick Mathewsonnickm@torproject.org2022-11-22T20:07:14Zurn:sha1:bc1de60d6d31b2c01262398741757113636dd4bc
This commit makes it possible to replace the default channel factory
(used when there is no PtMgr), and to replace the PtMgr.
This is part of #659.
ChanMgr: move the AbstractChanFactory into MgrState.2022-11-22T19:41:44ZNick Mathewsonnickm@torproject.org2022-11-22T19:38:02Zurn:sha1:a688e4afc9aa6e4273617eef21dd73bf8aabc329
We will want the freedom to replace this, so it needs to go behind a
lock. We need to be able to Clone it cheaply now, so we're using an
Arc instead of a Box.
Replace TransportRegistry with AbstractPtMgr2022-11-22T18:09:06Zetator@eta.st2022-11-22T18:01:32Zurn:sha1:2f75702cec4d58ce64ddca5a0ea28a6ab8cd853c
It doesn't make much sense to have the pluggable transport manager be a
registry, so replace its interface with a more narrowly defined, less generic
version.
Other changes:
- instead of returning a &-reference, it returns an owned Arc, which
should make the ptmgr easier to implement while allowing efficient
reuse
- provision for error handling is added, but will probably be revised in
a future commit pending discussion
- tor-ptmgr code that would generate warnings as a result of this change
is temporarily removed
This is a split out version of arti!886, intended so work on arti#659
can proceed.
Run add_warnings.2022-11-03T15:06:02ZNick Mathewsonnickm@torproject.org2022-11-03T15:06:02Zurn:sha1:932fe48eaf83f456eefd59475b4486d59966dec3