mirrors/arti.git/crates/tor-ptmgr/src/config.rs, branch arti-v1.2.2

ptmgr: Use impl_standard_builder for TransportConfig

2024-04-02T16:38:29Z

(This is !Default, since there is no default TransportConfig.)

tor-ptmgr: Comment fixes

2024-03-14T20:02:46Z

Clean up parts of the ptmgr docs that assume managed pts

2024-03-14T20:02:46Z

Teach get_cmethod_for_transport to handle unmanaged transports.

2024-03-14T20:02:46Z

This will suffice to bypass the reactor when we're dealing with an unmanaged pluggable transport. Closes #755.

Adapt TransportConfig to support unmanaged transports.

2024-03-14T20:02:46Z

This is based on an original branch by Trinity. Instead of its original approach, which used an enum in the configuration to distinguish managed from unmanaged transports, this branch uses builder validation function to ensure that incompatible options aren't used together. Doing the lets us generate better error messages. Thanks: trinity-1686a

Rename ManagedTransportConfig to TransportConfig.

2024-03-14T20:02:46Z

We're going to start using this type for _every_ kind of transport.

tor-guardmgr: bridges: fix typo in getter doc

2023-07-21T09:48:16Z

tor-guardmgr: bridges: getter for ManagedTransportConfigBuilder.protocols

2023-07-20T15:42:03Z

It's a bit of a wart that tor-ptmgr calls these "protocols" and tor-guardmgr calls these "transport names".

Additional documentation around bridges/PT configuration

2023-07-03T17:00:25Z

This tries to flesh out some of the details for users who may be new to bridges and PTs. Closes #706.

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