| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Thanks to our previous changes, we no longer need this type, or the
methods that access it.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is necessary so that we can look up channels (open and pending)
by all of the Ids that we know about them.
The operations needed here are pretty complex: to get them right,
I've replaced most of the accessors on the inner `ChannelMap` with a
function that holds the lock while another `FnOnce` is called. This
still gets us the invariant that we can't accidentally await while
holding the lock on the `ChannelMap`.
I've removed the tests for the accessors that are no longer there.
There are some subtleties here. Now that we have more than one kind
of Id, it's possible to have a partial match. I've tried to explain
all these cases in the comments.
}
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Even though channels are practically changeable, they use locks
internally so that you don't need a `&mut Channel` to send or
receive traffic. It makes sense for reparameterizing the channel to
also use a &self reference.
I'll need this so that I can store channels in an `ByRelayIds<>`
set, and still invoke their reparameterize methods.
|
| | | |
| | |
| | |
| | |
| | | |
This will let us migrate from `HashMap<Ed25519Identity, Entry>` to
`ByRelayIds<Entry>`.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is mostly a testing only change for now too, but soon I'll use
it to deal with the fact that we need to know the IDs to actually
build a channel at all.
|
| | | |
| | |
| | |
| | |
| | | |
This is mostly a testing-only change for now, but soon I'll use it
so we can have IdMap for our channel map.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The `ByRelayIds` type doesn't have a type equivalent to
`hash_map::Entry`, since it's a set type rather than a map
type. Therefore, the only plausible way to do entry mutation will
be to remove the old entry and insert a new one. And so, we no
longer need a "poisoned" state.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Add a few tests for RelayId and friends
Closes #605
See merge request tpo/core/arti!774
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| |\
| |
| |
| |
| | |
ChanMgr: Reorganize factory, builder, transport code.
See merge request tpo/core/arti!771
|
| | | |
|
| | |
| |
| |
| |
| | |
Since there is no longer a blanket implementation of ChannelFactory
for TransportHelper, we no longer need a separate type here.
|
| |/
|
|
| |
There is no actual code change here: just movement.
|
| |\
| |
| |
| |
| | |
Fix some rustdoc errors.
See merge request tpo/core/arti!770
|
| |/
|
|
|
|
| |
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
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This will prepare for supporting multiple different ChannelFactory
implementations.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This lets us build channels using different TransportHelpers,
including the (new) default TransportHelper, which just uses the old
connect_to_one() code.
|
| | |
| |
| |
| | |
This will let us just have ChanMgr take a `dyn ChannelFactory`.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The traits that launch connections need to be async; the traits that
don't, shouldn't be async.
Additionally, we need a few more "Sync" annotations here for the
futures to work.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is an internal type (distinct from factory::ChannelFactory)
that we use to make the code in `tor_chanmgr::mgr` agnostic about
what a channel actually is, and how it is actually launched.
Therefore, I'm renaming it and giving better documentation in a
couple of places, to prevent confusion.
|
| | |
| |
| |
| |
| |
| | |
* Get `TransportId`
* Get the target address (of any type)
* Ask, "is this a direct connection"?
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Abolish maint/readme and use doc include
Closes #603
See merge request tpo/core/arti!768
|
| | |
| |
| |
| | |
This is not needed any more
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| | |
| |
| |
| | |
Add some dummy definitions that support the example.
|
| | |
| |
| |
| |
| |
| | |
Add fn main wrappers to allow use of ?.
Add ,no-run to test cases that fail due to accessing the filesystem.
|
| | |
| |
| |
| | |
Add ,ignore to ignore three shell runes.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Add ,ignore to ignore three examples that don't actually compile.
cargo readme would add these annotations to lib.rs, but the doc
include doesn't do stuff like that. pandoc seems to still render the
result just fine.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Rename Bridge to BridgeConfig
Closes #599
See merge request tpo/core/arti!767
|
| | | |
| | |
| | |
| | | |
Fixes #599
|
| | |/ |
|
| |\|
| |
| |
| |
| | |
Add bridges configuration section
See merge request tpo/core/arti!744
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This demonstrates that:
* !bridge-client: uncommenting nondefault bridge config generates
urecognized config key warnings (but the config is still accepted)(
* bridge-client, !pt-client: uncommenting nondefault bridges generates
error due to attempting to use a PT. If that's filtered out,
everything is fine.
* pt-client: Everything is good (as before).
|