| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
| |
When negotiation won't occur, we need to represent the fact by
disabling any settings that would depend on negotiation.
Otherwise we'll wind up with the client thinking everything
was supported, and the relay thinking that nothing is.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The fallback CC algorithm is _always_ fixed-window, and we should only
use it when the selected CC algorithm is not supported.
|
| |
|
|
|
|
|
|
|
| |
Now tor-circmgr no longer needs to check which Protover capabilities
are enabled, or construct a separate CircParameters for each hop.
Instead, tor-proto decides whether to use the fallback CC mode,
based on whether the target supports FLOWCTRL_CC.
Closes #1967.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
One type will now represent _the kind of hop we are asking
tor-proto to negotiate_; the other will represent
_the state of such negotiation_.
This doesn't simplify the code much yet, but it will be helpful
as we add more and more negotiable settings.
Part of #1967
|
| | |
|
| |
|
|
|
|
| |
Previously it did not behave correctly when `bucket.max()` was 0 (it
would sleep for 0 time instead of infinitely, triggering a debug
assertion).
|
| | |
|
| | |
|
| |
|
|
| |
The token bucket is now refilled before changing the rate.
|
| | |
|
| | |
|
| |
|
|
| |
The user now sets a constant amount of bytes to wait for.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Unfortunately the git diff thinks I moved the struct, but I really only
moved the comment.
|
| |
|
|
|
| |
`DataWriter` -> `DataWriterInner`
`DataWriterNew` -> `DataWriter`
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1969.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
There's already a check right above the TODO that does what the TODO
asks.
|
| |
|
|
| |
This addresses one of the TODOs from `reactor::conflux`.
|
| | |
|
| |
|
|
|
| |
This is not a MUST for client-side conflux, so I'm filing it as tech
debt.
|
| | |
|
| |
|
|
|
|
| |
We don't have a way to compare virtual hops (see #2016), and we don't
yet support onion service conflux (see #2002), so let's defer this for
now.
|
| |
|
|
| |
This is tech debt, and is not a MUST for conflux.
|
| |
|
|
|
| |
We can tackle this later, after we finish addressing all the remaining
`TODO(conflux)`.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: Prevent sink and rx from being dropped in-place.
Closes #2005
See merge request tpo/core/arti!3005
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This was supposed to be fixed in 164d6b4d6c5, but that change failed to
bind `sink` and `rx in `futures::join!`, causing `sink` and `rx` to get
dropped, which would, in turn, cause the channel and circuit reactors to
shut down, sometimes leading to intermittent failures (#2005).
Closes #2005
|
| | | |
|
| | |
| |
| |
| | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3002#note_3200935
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit c2d9ea952b4dcb91d05ee754e8d1a6ec6a0689b2.
`QueryLegs` is now unused. We also decided we won't need it for
implementing `Tunnel::path_ref()` as we are keeping the
`MutableState` between `ClientCirc` and the reactor (see !2996).
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, `ClientCirc:allow_stream_requests()` would return an error
when called on a multi-path tunnel.
My main reason for removing the conflux set length check is because it
enables us to remove the `QueryLegs` control command (which is something
we were planning on doing anyway).
Note that now that we've removed `ClientCirc::legs(), there's no way for
a multi-path `ClientCirc` to access its circuit legs, but that is fine,
because it's currently impossible to build multi-path `ClientCirc`s in
arti anyway. This issue will be addressed in the fork, in the new
`ClientTunnel` type that will be used for multi-path tunnels (a
`ClientCirc` will only ever be single-path, so it won't need to have a
`legs()` function at all).
I am also removing the `TODO(conflux)` that justifies the now-removed
check, because it's outdated (nowadays the `CellHandlers` are shared
between the tunnel reactor and its circuits). That said, we *still*
don't support onion service conflux, but that will be tackled separately
because there are a bunch of issues that still need to be resolved to
make it work (which I'll document separately).
Note that I've also made some changes to pass the `LegId` of the circuit
that received the incoming stream request to `StreamReqInfo` and
`StreamTarget`. This is in preparation for supporting multipath onion
service conflux, and because the `HopLocation` from `StreamTarget`
*needs* a `LegId`.
|
| | |
|
| |
|
|
|
| |
These `TunnelMutableState` impls just delegate to `MutableState`, so we
might as well link to the corresponding docs.
|
