mirrors/arti.git/crates/tor-chanmgr/src/factory.rs, branch arti-v1.2.8

tor-chanmgr: add experimental `ChanMgr::handle_incoming`

2024-09-11T18:15:16Z

The channel manager in the future will need to be able to receive incoming streams. The type of the stream depends on an associated type within `ChannelFactory`, so this commit exposes this associated type through several other types, eventually to the `ChanMgr`. The new methods are behind the experimental "relay" feature flag.

tor-chanmgr: make `CompoundFactory` generic over `ChannelFactory`

2024-09-11T18:14:33Z

This has two advantages: 1. Code is a little easier to follow with generics rather than dynamic dispatch, especially since the type is fixed at compile time anyways. 2. It allows us to access associated types of the `ChannelFactory`, which will be useful later for getting the stream type from the `ChanBuilder`.

proto: Make Channel explicitly Arc<.>

2024-05-16T16:24:12Z

Previously, Channel was a type that you could Clone that implicitly its state. Now, Channel always appears as an Arc. This change has several benefits: * It makes the relationship between Channel struct and the underlying channel more clear. * It enables Channel to participate in the RPC system, where everything has to be an Arc<.> * It enables us to have a Weak, if we ever want to. * It will let us move various members out of ChannelDetails. We did this change a while ago with ClientCirc.

Resolve a pair of warnings about redundant closures.

2023-08-22T16:24:51Z

Rename TransportHelper => TransportImplHelper.

2022-11-30T18:05:46Z

Abolish ChanMgr::set_default_transport

2022-11-30T16:00:31Z

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.

chanmgr: Report Pt errors correctly.

2022-11-29T16:10:26Z

We were panicking if the PtMgr gave us an error, which isn't so good.

tor-chanmgr: Introduce the BootstrapReporter API, publicize ChanBuilder

2022-11-28T18:52:21Z

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).

Draft: Pluggable transport manager

2022-11-28T18:52:21Z

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`.

ChanMgr: Another attempt to build on CI.

2022-11-23T16:25:15Z