| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This fixes a `clippy::large_enum_variant`.
|
| | |
|
| |
|
|
| |
We do something similar with non-virtual hops at !4076.
|
| | |
|
| |
|
|
| |
This better matches nearby code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is part of an implementation for proposal 368.
|
| |
|
|
| |
These will be shared with the relay code.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #2067.
|
| | |
|
| |
|
|
|
| |
This makes it easier to see which parts are implementation-agnostic
(i.e. do not import from crate::client).
|
| |
|
|
|
| |
Some of these are relay-specific, so it makes more sense to pull this
into a top-level module.
|
| | |
|
| |
|
|
| |
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 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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
|
| | |
|
|
|
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|
