| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously when initializing a stream, we constructed most of the
stream-related queues outside of the reactor and passed the relevant
halves of the queues (senders or receivers) into the reactor.
A downside of the above approach is that the reactor may be better
informed about what queues to construct, and how to construct them. For
example the reactor knows what type of flow control that the hop is
using, so it knows whether we need queues for passing rate limits and
drain rates for XON/XOFF flow control.
This commit moves the construction of these queues into the reactor and
passes the relevant halves out of the reactor. In the future we can make
better decisions about which queues are needed depending on the flow
control method used instead of always constructing them (see arti#2068).
Reviewing with `--color-moved` might be helpful as a few lines have been
moved.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The stream queue length (for messages incoming from the Tor network)
depends on the type of flow control we're using for the hop. Currently
we construct the stream queue outside of the circuit reactor, but we
don't have the flow control information here.
Instead of constructing the stream queue outside of the reactor and
passing the sender into the reactor, we construct the stream queue
inside of the reactor and pass the receiver out of the reactor.
|
| |
|
|
|
|
|
|
|
| |
This will make it possible to tell whether a path has been replaced
in the tunnel.
Since the UniqId type might change its representation in the future,
I've documented that we don't guarantee anything about the strings
used to distinguish paths.
|
| |
|
|
| |
Additionally, allow inspecting tunnel paths directly from streams.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| |\
| |
| |
| |
| | |
proto: Start handling incoming streams in the relay reactor
See merge request tpo/core/arti!3487
|
| | |
| |
| |
| | |
All this indirection is making me dizzy.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is needed because we want to reuse `StreamTarget` and `DataStream`
on the relay side too, but to do that, we need to abstract away the
tunnel/circuit type (prior to this MR, `StreamTarget` was was
client-specific, as it used to wrap a client tunnel).
Note that `StreamTarget` needs a handle to the client/relay circuit
reactor because it needs to be able to shut down the circuit if a
protocol error occurs (cells carrying stream data are parsed late,
*outside* of the reactor, so if e.g. a cell fails to parse, the
`DataReaderImpl` needs to be able to shut it down), and because it needs
to be able to inform the reactor of flow control-related events (such as
drain rate update).
|
| | |
| |
| |
| | |
For relays, the hop of the StreamTarget will be set to `None`.
|
| | | |
|
| | |
| |
| |
| | |
We are about to use `StreamReqInfo` for exit streams too.
|
| |/
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This only moves code from src/channel to src/client/channel.
It introduces a ClientChanBuilder that is used to launch client specific
channel by the public ChanBuilder.
The followup commits will add a VerifiedClientChannel and
UnverifiedClientChannel in order to again decouple client and relay code
from the generic objects.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
| |
This is part of an implementation for proposal 368.
|
| | |
|
| |
|
|
| |
These will be shared with the relay code.
|
| |
|
|
|
|
| |
That way we don't need to make halfstream `pub(crate)` (we only really
use it in streammap, and in the client reactor, because of the
`handle_msg()` kludge).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We need it for exits and leaky pipe.
Part of #2212
|
| | |
|
| |
|
|
|
|
| |
The previous "incoming" terminology was rather ambiguous.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337
|
| | |
|
| |
|
|
|
| |
This makes it easier to see which parts are implementation-agnostic
(i.e. do not import from crate::client).
|
| | |
|
| | |
|
| |
|
|
| |
This will be used by exits too, so I am moving it out of `client`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For now, we're not going to implement hop negotiation: we're still
waiting to find a set of padding machines that will be useful for
Arti. This API will help facilitate experimentation to find such
padding machines.
These APIs are under a separate feature (`circ-padding-manual`)
to avoid confusing them with the rest of the padding code:
we only want them to be exported when the researcher wants to
manually install circuit padding.
|
| |
|
|
|
| |
For internal types, I think it becomes too much of a mess to export
everything through a single module.
|
| |
|
|
| |
This is all private (or pub(crate)) code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `TunnelId*` types will be reused in the relay reactor (exit relays
need to have the concept of a "tunnel ID" because of conflux).
Now the `relay::reactor` module only has a single import from `client`
(for the `unwrap_or_shutdown` helper, which we should be able to remove
soon). From now, we will avoid importing anything from `client` in the
`relay` module, and instead prefer refactoring the code as needed (to
pull the implementation-agnostic parts outside of `client`).
This commit has no functional changes, just code motion.
|
| |
|
|
|
|
|
| |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| | |
|
