| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This puts in, based on the circuit parameters, the CC extension request
in the CREATE and EXTEND requests.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Congestion control can change the circuit parameters if the relay we are
negotiating with doesn't support FlowCtrl=2.
This commit adds a function in the circuit builder that will apply any
changes to the circuit parameters of the hop based on the hop protocol
values. For now, only congestion control applies.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This avoids cloning the object and instead allows us to have a
CircParameters per hop on the circuit path. This will come handy with
congestion control where each hop might have different congestion
control parameters.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
CircParameters is built before path selection and thus once we start
building the hops, we can't access the consensus values that were used
to build it in the first place.
For congestion control, we require a fallback algorithm in case the hop
doesn't support FlowCtrl=2.
This commit adds a "fallback_alg" to the CC parameters which will be
used for this exact case.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When receiving the congestion control response extension, evaluate our
state and set the sendme_inc if valid in our circuit parameters.
For this, a series of helper functions is needed.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is required because circuit ntor v3 handshake can negotiate circuit
level parameters and thus able to change any values.
Needed for congestion control ntorv3 handshake extension for which the
sendme increment is negotiated.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
various crates: MSRV TODO standardization and cleanup of an old TODO
See merge request tpo/core/arti!2945
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- After spending quite a while trying to figure out why the tests kept failing
after making the change, I eventually stumbled upon the netdoc syntax
specification, which helpfully informs me that newlines MUST be ignored and
discarded. Switching to using [`str::split_inclusive`] would either require
extra lines to workaround and recreate the current expected behavior or changing
the spec and correcting the tests to align with the new expected behavior.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- 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. For
this one in particular, we actually do already meet the MSRV specified, but I
want to check on the implementation details to see if this is still desired,
since the TODO is 4 years old.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
- 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 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 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 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 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.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
- https://github.com/rust-lang/rust-clippy/issues/11764 was fixed upstream, so
this is no longer needed.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
arti-client: Remove incorrect note about `StateDirectory` usage
See merge request tpo/core/arti!2952
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
integration-e2e-shadow flakiness debugging and workaround
See merge request tpo/core/arti!2950
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since this significantly affects the behavior of the simulation, it's
probably worth having it in the yaml. (It can of course still be
overridden from the command-line).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since this significantly affects the behavior of the simulation, it's
useful to have it in the yaml for reference or if the simulation is
manually rerun from the yaml.
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This should make the simulation results generally more stable with
respect to small perturbations, such as adding logging.
It also causes a previous "heisenbug" failure in this test to reliably
reproduce in every run.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Enforce recommended and required protocol versions in arti-client
Closes #1849 and #1923
See merge request tpo/core/arti!2929
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This name reflects its purpose better than the original one,
since it includes required protocols as well as recommended ones.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Also move the comment outside the block it documents,
to prevent a too-long line.
|
| | | | |
| | | |
| | | |
| | | | |
Also wait a little so logs can flush.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This rule makes PartialEq more sensible.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In the directory code, we have functionality to advance the
consensus download state whenever possible, even if there is more we
could download in the current state.
That's fine, but when we're in this position, we need to be sure
that we're taking any action based on the current state (such as
installing notably parameters or, notably, protocol recommendations)
before we move on.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
(This isn't a boolean, because we really don't want people ignoring
all possible required protocols.)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This doesn't need to be perfect, but we need to use it to see
if a consensus is new enough that we should obey its
recommendations.
This commit also adds a script to update or check our release date,
and calls this script from our cargo-publish script.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This is the major part of #1849.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We want to store this separately from the consensus,
because we want to access it very early in our load-from-cache
process, without checking the consensus that contains it
for timeliness.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We'll want this so that we can expose them before we expose the rest
of the consensus (which we need to do for spec conformance).
|
| | | | |
| | | |
| | | |
| | | | |
Also, add a new ErrorKind for this sort of error.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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).
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Closes #1923
|
| | | | | |
|