| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| |
|
|
|
|
|
| |
This lint exists for perf reasons, and this is rarely relevant in
tests.
Using double quoted str is generally cognitively less burdensome.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
Also, document the features.
Closes #588.
|
| | |
|
| |
|
|
|
|
|
| |
Try to clarify more that the ChannelUsage is for describing the
usage for one particular channel request, not for the channel as a
whole. This is a potentially confusing point, so we should spell it
out completely.
|
| |
|
|
|
| |
We now log connection attempts at debug!, and mark relay target
addresses as sensitive.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Making ChannelPaddingInstructions::default() accurately reflect the
initial state of the reactor's padding timer simplifies the code
somewhat.
(When padding is wanted, parameters are computed and inserted
explicitly, so the only change is that if we start out dormant, we
defer setting the timer parameters until necessary.)
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2827249
|
| |
|
|
|
| |
As suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2827246
|
| |
|
|
|
|
|
|
| |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2827242
These texts were out of date; one of them still mentioned
`all_zeroes`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes "chanmgr configuration: Avoid sending needless initial update(s)"
|
| |
|
|
| |
This allow us to make a working cross-reference.
|
| |
|
|
| |
Run rustfmt; no other changes.
|
| |
|
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826167
This makes some lines too long; I will run rustfmt in a separate
commit for clarity.
|
| |
|
|
|
| |
Reported here
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826166
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826164
|
| |
|
|
|
| |
It turns out that the TryFrom was infallible, which wasn't obvious
with the previous code structure.
|
| |
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826151
This gets rid of quite some Bug error paths.
|
| |
|
|
|
|
|
|
|
|
|
| |
Replace Channel::note_usage with Channel::engage_padding_activities,
which unconditionally causes the channel to (start to) do netflow
padding things.
The condition now lives in chanmgr.
Addresses
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826094
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826093
|
| |
|
|
|
|
|
|
|
| |
The network consensus parameters use (0,0) to mean "no padding"
(which is not the same as (0,0) means in a PADDING_NEGOTIATE cell).
Representing "no padding" this way is actually quite convoluted and
un-Rustic. Ensure that we convert (0,0) to None, and do the primary
logic in Option.
|
| |
|
|
|
|
|
| |
Roughly as suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826160
IMO this is less clear, because of the way it splits the logic up.
|
| | |
|
| |
|
|
| |
No functional change. (The error tyep was Void.)
|
| |
|
|
|
|
|
|
|
| |
This gets rid of many Result(). Many parameters are renamed.
Test cases of the now-impossible branch are removed.
Deleting the match from padding_parameters will come in a moment.
I've split off that commit since it has much whitespace noise.
for now, change the error type to Void.
|