| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The BaseTunnel now has a start_conversation() which takes a TargetHop
meaning it can be used with a multi path tunnel.
The Conversation object has been moved into the tunnel namespace out of
the circuit one.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to pull this off, the Arc requirement needs to go away because
the Arc<ClientCirc> is now within the ClientTunnel.
This commit also has a rename of the CircuitBuilder to TunnelBuilder in
order to reflect the change that it now builds a ClientTunnel.
There is a slight rename in tor-proto as well just for accuracy.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
And rename it in the process to "PendingClientTunnel".
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduce the new Tunnel structs that is planned to expose publicly as a
replacement to `ClientCirc`.
Future commits will make those tunnel objects be used accross the code
base up until tor-proto which than handles Circuit directly.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to pull this off, some client => tunnel renaming needed to
happen including the comments.
The send_raw_msg() is an experimental and expert mode method that any
tunnel should have access to in order to be able to send whatever
message in whatever tunnel type.
No behavior changes.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To use the functionality only allowed on single-circuit tunnels (such as
`extend*`), callers will have to call `ClientTunnel::as_single_circ()`
to obtain a handle to the underlying `ClientCirc`.
This is an opinionated design decision that goes against the plan from
[!2790]. It stems from my thinking that it would make more sense to keep
`ClientCirc`, than to merge it into `ClientTunnel`. If we merge the two,
many functions will need become fallible and less ergonomic, because the
user of `ClientTunnel` needs to know whether the `ClientTunnel` consists
of a single-circuit or not. Providing (fallible) access to the
underlying `ClientCirc` of the `ClientTunnel` seems simpler than the
alternative. That being said, I am open to switching back to the
original plan if this design turns out to be annoying to work with.
[!2790]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2790
|
| |\ \
| | |
| | |
| | |
| | | |
Fix errors from rustdoc nightly.
See merge request tpo/core/arti!3124
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This was accidentally omitted from my version bump script.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Made with the following shell script:
export CARGO='nailing-cargo -Eu'
# Non-functional changes only
maint/bump_nodep hashx
# Special
$CARGO set-version -p arti 1.4.6
# Additional features, no breaking changes, depended on in tree
$CARGO set-version -p safelog 0.4.8
# Unconditional bump to 0.33.0
xargs -I P <<END $CARGO set-version -p P 0.33.0
tor-error
tor-general-addr
tor-geoip
tor-rtcompat
tor-rtmock
tor-async-utils
tor-config
tor-config-path
tor-rpc-connect
tor-log-ratelim
tor-rpcbase
tor-memquota
tor-units
tor-llcrypto
tor-bytes
tor-protover
tor-checkable
tor-cert
tor-key-forge
tor-hscrypto
tor-socksproto
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-consdiff
tor-netdir
tor-relay-selection
tor-persist
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
tor-hsrproxy
tor-relay-crypto
arti-client
arti-relay
arti-rpcserver
arti-ureq
arti-rpc-client-core
END
|
| |/
|
|
| |
No upstream changes that break our code.
|
| |
|
|
|
|
|
| |
This command is supposed to return an error when handled by a tunnel
reactor that has more than one circuit.
Prevents the `ConfluxSet::take_single_leg()` bug fixed in 00bb0628.
|
| |
|
|
| |
This was fixed in !3091
|
| | |
|
| |
|
|
|
|
|
| |
This slightly reduces the amount of code we need to maintain.
This also drive-by fixes a bug in `ConfluxSet::take_single_leg`, which
previously never actually checked if the conflux set was of size one.
|
| |
|
|
|
| |
This method will enable us to remove some duplicated code, as well as
the `element_idx` function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit prevents us from ever deciding that another relay
supports CGO, which prevents us from trying to negotiate it.
It also adds an assertion to make sure that we haven't tried to
negotiate it.
We can remove this once we're ready to have CGO turned on:
right now it's blocked on being able to negotiate CC.
I'm adding this so we can merge this branch (so that I can stop
rebasing it.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We now take an enum describing whether we are doing no negotiation,
HsV3 negotiation, or full negotiation. This lets us do away with
the notions of default relay crypto, and of declaring post-facto
that no negotiation has occurred.
|
| |
|
|
|
| |
Instead call it compatible_with_cgo, which is what we actually
care about in this context.
|
| |
|
|
| |
Let's see if it works!
|
| | |
|
| |
|
|
|
| |
Since these will be negotiated (or determined as part of negotiation)
they belong in HopSettings.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`DataReader` -> `DataReaderInner`
`DataReaderNew` -> `DataReader`
This means that the `DataReader` now supports XON/XOFF flow control
using the `XonXoffReader`.
This means that it can receive requests for a new drain rate from the
reactor, and can send the new drain rate to the reactor once there is no
more stream data queued.
|
| |
|
|
| |
This will later become `DataReader`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The idea here is that the reactor builds an `XonXoffReaderCtrl` for the
new stream, and the `XonXoffReaderCtrl` can receive notifications from
the reactor's `StreamFlowControl`. The `XonXoffReaderCtrl` can be
combined with any `AsyncRead` to build a `XonXoffReader`, essentially
wrapping the `AsyncRead` with a type that handles XON/XOFF flow control.
Essentially, the reactor gives you a type that allows you to add
XON/XOFF flow control support to any `AsyncRead`.
We will add this `XonXoffReader` to the `DataReader` in a future commit.
|
| |
|
|
|
| |
Nothing actually causes an XON to be sent yet. But this adds the code so
that anything holding the `StreamTarget` can request to send an XON.
|
| | |
|
| |\
| |
| |
| |
| | |
tor-proto,tor-cell: Code refactoring and add support for sending XOFF messages
See merge request tpo/core/arti!3094
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
XON/XOFF flow control will want to know how many data bytes are queued
on a stream, so the new types track that.
|
| | |
| |
| |
| |
| |
| | |
As we continue adding more functionality to streams like flow control,
we'll have more objects to pass around. This tries to group them
together.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The plan is to use `StreamSendFlowControl` (now `StreamFlowControl`) for
both outgoing and incoming directions, so a name change is needed.
This also updates some comments, and renames some related struct fields
that have the word "send" in them.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This allows us to extend the command to implement different flow control
methods. We could add new command variants for new flow control methods
instead, but I think it makes sense to have them be a single command as
they will always have a stream ID / hop location in common. This also
helps us keep the flow control logic in one place.
|
| | |
| |
| |
| |
| | |
I don't see any further changes being needed for these types, and it
simplifies a lot of future code in tor-proto that uses these types.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The `Ord` impl of `OooRelayMsg` already "reverses" the seqno comparison,
which means previously we were double-reversing it (leading to the ooo
cell heap logic being broken in cases where its size was > 1).
Caught by the new conflux switch handling tests.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The two mock exit legs will use this channel to notify each other of the
receipt of BEGIN cells. This will enable us to extend the tests to
support writing cells to the stream (but only after the stream is
opened).
|
| | | |
|
| | |
| |
| |
| | |
This abolishes the overly-long tuple used in these tests.
|