| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This will allow the PowManager to have a copy of RendRequestReceiver,
which is important to allow the PowManager update loop to control the
suggseted_effort updating.
|
| | |
|
| |
|
|
|
|
|
| |
This makes the suggested_effort value a Arc<RwLock<Effort>>, which is
shared between the PowManager (as a reader) and the RendRequestReceiver
(as a writer), since the RendRequestReceiver has the information needed
to update the suggested_effort value.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The updated PoW control loop in prop362 requires this data structure to
be double ended, which BinaryHeap is not. I benchmarked [email protected]
against BTreeSet on a synthetic benchmark based on what I expected
typical load to look like, and found that BTreeSet performed much
better. It is additionally in the standard library, and is maintained,
which no third-party double ended priority queue crate seems to be.
Given that, BTreeSet seems like a reasonable thing to build on, although
we should provide metrics on the performance of this queue so operators
can let us know if it seems to be a problem in real-world use.
|
| |
|
|
|
|
|
| |
Since this will be used in a BTreeSet, we need to ensure that in
practice no two requests will be equal. Ordering by a combination of
effort and time received should be sufficient for this, and gives us the
behaviour we want.
|
| |\
| |
| |
| |
| |
| |
| | |
Implement proposal 360 (limit HsDesc inflation opportunities)
Closes #2046
See merge request tpo/core/arti!3070
|
| | |
| |
| |
| |
| | |
It would be better to take a more sophisticated approach;
see #2048.
|
| | |
| |
| |
| |
| | |
These errors are suspicious as hsdir inflation attacks, in the
context of prop360.
|
| | | |
|
| |/
|
|
| |
Made with https://crates.io/crates/typos-cli
|
| | |
|
| |
|
|
| |
See #2060.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This requires some changes to the tor-proto crate to handle the inbound
TargetHop from the HS subsystem and then resolve it into a HopNum for a
single circuit.
It is expected that this will change again with Conflux to only use
HopLocation internally in a Tunnel and then use HopNum into a Circuit.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order for this to work, a last_target_hop() function is added to
ClientCirc in order to return a precise hop location as a TargetHop of
the last hop.
This is needed because in the HS subsystem, we need such value in order
to get a location on the last physical hop before adding the virtual
hop.
The RDV1 cell is sent to that last target hop while the
allow_stream_request() is done on the virtual target hop.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This is in the spirit of making everything going inbound the tor-proto
crate to use a TargetHop.
This becomes much easier for the HS subsystem as it only uses the last
hop for its conversation and setup.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to use TargetHop instead of HopNum but also to get one
step closer to not depend on a mutable state.
We prefer resolving a TargetHop within the Reactor object in order to
use the circuit list instead of the MutableState path.
The HS service subsystem is modified to use this modified function that
is now async and uses a TargetHop.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
We will construct this object based on the circuit parameters _and_
on the target's supported protocol versions, so we need to do so
when we have both pieces of info.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently clippy nightly is better (or worse?) about detecting
complex functions than before, so I'm suppressing these warnings
where they occur.
I have mixed feelings about these warnings: On the plus side,
they really do help to detect functions that are twistier than they
need to be. On the minus side, they get confused by tracing macros,
and the "allows" do pile up. But on the plus side, those "allows"
do provide a way to find functions that need to be refactored,
and they are never uglier than the functions they decorate.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This adds a error type for internal errors, and in error cases where we
previously panicked, returns a Result instead. The publisher then simply
doesn't publish the pow_params line and warns the user.
|
| |
|
|
|
| |
This shouldn't happen, but there's not a good reason to panic if it
does.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will allow us to more easily switch out the implementation of this
queue as is needed for PoW.
|
| |
|
|
|
|
|
| |
This adds PowManager, as described in doc/dev/notes/service-side-pow.md,
hooks it into IptManager and Publisher, and adds code to publish and
rotate seeds, and to keep a updated list of Verifier instances for
currently active seeds.
|
| |
|
|
|
|
|
| |
The `IoError::other` function is an easier way to say
`IoError::new(IoErrorKind::Other, ...)`. It's been around since
1.74, but clippy started warning about the more verbose version in
1.87.
|
| |
|
|
|
|
|
|
| |
This is messy, because `ClientCirc::{path_ref, n_hops, ..}` become
fallible (we can't unwrap the result, because when a circuit is closed,
its state gets removed from the `TunnelSharedState`, but its
`ClientCirc` handle continues to exist, so any attempt to retrieve the
state will result in an `Err`).
|
| |
|
|
|
| |
Now that our MSRV is 1.83, clippy is happy to make more
recommendations for us.
|
| | |
|
| |\
| |
| |
| |
| | |
various crates: MSRV TODO standardization and cleanup of an old TODO
See merge request tpo/core/arti!2945
|
| | |
| |
| |
| |
| | |
- Part of a series of commits aimed at replacing all MSRV-related TODOs with a
standardized format, which should be easier to find when the MSRV is bumped.
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Part of #1849.
Note that these functions are distributed across crates,
so that if (in the future) we stop doing API breaks
with every release, we will get the right outputs.
Note also that these functions build the list of protocols
out of specific symbolic features, rather than numbers:
this makes it easier to avoid errors about "which feature was
Relay=4 again", and easier to avoid accidentally referring to a
protocol that doesn't exist, like "Consensus" (should be "Cons")
or "HsDir" (case is wrong).
|
| |
|
|
|
|
|
|
|
|
|
| |
We want to require that whenever we generate a key that's persistent
(stored in KeyMgr), it's going to be made from a stronger-than-usual
Rng. This trait helps us enforce that.
We also add a FakeEntropicRng struct to use for testing.
Note that this turned up a case that we'd missed, which required
an internal change in tor-hsservice.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
protover: Add support for subprotocol version mnemonics.
Closes #1891
See merge request tpo/core/arti!2854
|
