| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| |
|
|
| |
This resolves a number of TODOs.
|
| | |
|
| |
|
|
|
| |
This is not something we need to solve for 1.1.0 (and it might not
need to be solved ever).
|
| |
|
|
| |
We didn't find a use for this.
|
| |
|
|
|
| |
Since there are (or soon will be) parsing restrictions on this type,
we don't want to inline it as a simple Vec.
|
| | |
|
| |
|
|
|
|
|
|
| |
0.99.[012] have a bug https://github.com/JelteF/derive_more/issues/114
which makes the Deref derive for bridgedesc::StateGuard not work
and therefore breaks minimal-versions CI.
It seems simpler to require the newer version everywhere.
|
| |\
| |
| |
| |
| | |
Use ByRelayIds to hold guards in GuardSet
See merge request tpo/core/arti!808
|
| | |
| |
| |
| |
| | |
These are the ones that turned out to be necessary while converting
guard samples to use ByRelayIds.
|
| | | |
|
| |/
|
|
|
| |
The bridge descriptor manager wants to index data structures by the
BridgeConfig.
|
| | |
|
| |
|
|
| |
The singleton variation here is almost never what we want.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now it contains either an `OwnedChanTarget` or an `OwnedCircTarget`,
which will let `GuardMgr` return bridges that can be used to make
circuits.
As part of this change, it was necessary to revise some
address-modification functions that applied to filters and
`OwnedChanTarget`. Now they do the smart thing, and remove only the
address that are in the `ChanMethod`. This means that the addresses
from HasAddrs are still accurate about which addresses the relay
"has".
|
| | |
|
| |\
| |
| |
| |
| | |
serde support for PtTarget
See merge request tpo/core/arti!780
|
| | |
| |
| |
| | |
This will let us remember bridges that use pluggable transports.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `PtTarget` type and its contents (`TransportName`,
`PtTargetAddr`, `PtSettings`) are now unconditionally compiled and
exposed. This will allow us to serialize and deserialize them in
our guard-state files even when we have been built without explicit
PT support.
The `pt-client` feature controls whether `TransportName` is a
variant of `TransportId`, and whether `PtTarget` is a variant of
`ChanMethod`: this in turn means that we'll still have simpler
binary code and smaller structures when we're building without PT
support (which is what we wanted when we initially made these types
conditional).
|
| |\ \
| |/
|/|
| |
| | |
Use BridgeConfig to identify bridges in two places
See merge request tpo/core/arti!781
|
| | |
| |
| |
| |
| |
| | |
This lets us write functions which can either take an existing
owned OwnedChanTarget, or copy out of some other kind of ChanTarget
passed by reference.
|
| | | |
|
| |/
|
|
| |
Eg, a PT bridge may not have an address.
|
| | |
|
| |
|
|
|
| |
We need a function to remove an entry if it appears with _exactly_
the same relay Ids, but not otherwise. This method will do that.
|
| |
|
|
|
|
|
| |
Also, add a few tests for this and the other accessors.
We'll need this accessor to find whether we have any channels to
_any_ of the identities that we're trying to connect to.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We need to handle String, not just str, since some deserializers
have to handle escapes and generate new strings.
Found while writing tests; fixes #605.
|
| | |
|
| |
|
|
|
|
| |
In addition to the usual "You named that method wrong!" errors, we
have a new rustdoc error that complains about bogus "HTML tags" that
are actually unquoted usage of types like `Result<Foo>`.
|
| |\
| |
| |
| |
| | |
chanmgr: Build and use chanmgr factory APIs
See merge request tpo/core/arti!769
|
| | |
| |
| |
| |
| |
| | |
* Get `TransportId`
* Get the target address (of any type)
* Ask, "is this a direct connection"?
|
| | |
| |
| |
| |
| |
| |
| | |
Apparently cargo fmt doesn't like these, which my perl rune didn't
delete.
This commit is precisely the result of `cargo fmt`.
|
| |/
|
|
|
|
|
|
| |
The feature we want is `#[doc = include_str!("README.md")]`, which is
stable since 1.54 and our MSRV is now 1.56.
This commit is precisely the result of the following Perl rune:
perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
|
| |
|
|
|
| |
It looks like this got fixed, but my branch for !759 reintroduced it
by refactoring.
|
| |
|
|
|
|
|
| |
Now each `ChanTarget` has at most one `ChannelMethod`, and only
`Direct` `ChannelMethods` can have multiple addresses.
Closes #600.
|
| | |
|
| | |
|
| |
|
|
| |
All the other users of HasAddrs are correct.
|
| |
|
|
| |
These are now builders.
|
| | |
|
| |
|
|
|
| |
This will become the preferred way to make one of these objects, and
insulate us against future API changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HasAddr used to mean "Here are addresses that I have, at which I can
be contacted." But "Where (and how) can I be contacted?" is now a
question for HasChannelMethod to answer.
(We still need to have "HasAddr", though, so we can answer things
like "what country is this relay in" and "are these relays in the
same /8?")
So this commit introduces:
* A new trait for adding an implementation of HasChannelMethod in
terms of HasAddr.
* A requirement on ChanTarget that it needs to implement
HasChannelMethod.
There is some temporary breakage here, marked with "TODO pt-client",
that I'll fix later in this branch.
|
| |
|
|
|
| |
This is based on the type generated with n_key_set, with a
couple of extra methods to take advantage of RelayId and RelayIdRef.
|
| |\
| |
| |
| |
| | |
Parse (and format) bridge lines
See merge request tpo/core/arti!745
|
| | | |
|