Commit Graph

3 Commits

Author SHA1 Message Date
Saksham Mittal bbed17ba4a Add initial support for running a PT in server mode 2023-08-24 17:03:38 +00:00
eta 3b41c78d6f Draft: Pluggable transport manager
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-28 13:52:21 -05:00
eta a118a639ed tor-ptmgr/ipc: First cut of pluggable transport spawning
The new `ipc` module inside `tor-ptmgr` implements the Pluggable
Transport Specification version 1 (`pt-spec.txt`,
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/pt-spec.txt).

This enables module users to spawn pluggable transport binaries inside a
child process asynchronously, and receive structured information about
how to connect to the transports provided by said binaries.

Internally, this is structured as a pure set of serialisers and
deserialisers for the protocol in the specification (in the form of
environment variables, and the PT's stdout), a wrapper to run the PT
binary and enable accessing its output asynchronously, and a user-facing
wrapper that handles ensuring all the requested transports launched
properly.

The included `run-pt` example is an exceedingly minimal wrapper program
that was useful in testing. More tests can and should be added in a
further MR.

closes arti#394; part of arti#69
2022-10-26 16:07:30 +01:00