| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
|
| |
Also updated other packages to get `CfgPath` directly from
`tor-config-path' instead of 'tor-config'.
|
| | |
|
| |
|
|
|
| |
This conditionally compiles most of the code related to managed
transports.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is a little nicer and more type-safe to work with than
`TransportConfig`. It would have been nice to change `TransportConfig`
directly instead, but it would slightly change arti_client's public API,
and would require an extra field in the `[[bridges.transports]]` toml
table.
|
| |
|
|
| |
(This is !Default, since there is no default TransportConfig.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will suffice to bypass the reactor when we're dealing with
an unmanaged pluggable transport.
Closes #755.
|
| |
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
| |
|
|
| |
We're going to start using this type for _every_ kind of transport.
|
| | |
|
| |
|
|
|
| |
It's a bit of a wart that tor-ptmgr calls these "protocols" and
tor-guardmgr calls these "transport names".
|
| |
|
|
|
|
|
| |
This tries to flesh out some of the details for users who may be new
to bridges and PTs.
Closes #706.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
| |
This brings the draft configuration mechanisms in tor-ptmgr in line with
the config in other crates, using builders. It also plumbs the config
type through into the main `arti-client` config, and adds some example
lines to `arti-example-config.toml`.
|
| | |
|
|
|
When complete, this crate will handle launching and using pluggable
transports on demand.
|
