| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Having this be a `futures::Stream` makes it nicer to work with. For
example we are able to remove a boxed future from `DataReaderState`,
which should be better for performance and makes the code simpler.
As mentioned in a previous commit when this type was named
`StreamReader`, this type is public in the API, but is not actually
accessible. As far as I can tell there is no way to construct it or
access it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In rust, the typical nomenclature is to use "receiver" for channels, and
"reader" for byte streams. For example `mpsc::Receiver` for something
that returns objects and `AsyncRead` for something that reads bytes.
Since we also have a `DataReader` for reading bytes, I think renaming
this from `StreamReader` to `StreamReceiver` better describes what it is
(it's not a "reader" in the typical `Read`/`AsyncRead` sense).
This type is public in the API, but is not actually accessible. As far
as I can tell there is no way to construct it or access it.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
These functions have been deprecated for a while, and are now
complicating the `MutableState` changes we need to do for #1840, so it
seems like a good time to remove them.
|
| |
|
|
|
|
|
|
| |
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.30.0
done
```
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The constructor for rand::distr::Uniform is now fallible,
so it makes sense to bubble up its restrictions.
This is a breaking change.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is unused but most importantly it allows any RELAY cell to be sent
from anywhere in the code which is really not desirable because it is
skipping congestion control.
It also allows us to remove the `control_tx` from the reactor which is
one less channel to track/understand/think about.
This opens up the door to all sorts of problems especially side channel
that can be exploited if we are not careful.
We can always bring this back if we need it but for now, it is unused
and allows us to remove the `CtrlMsg::SendRelayCell` control message.
No code behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rewrites the circuit reactor main loop to use `select_biased!` to poll
multiple futures simultaneously.
The new `run_once()`, like the old, first waits for an initial
`CtrlMsg::Create`. Then, it uses a `select_biased!` to poll the
`chan_sender` sink and shutdown channel for readiness.
When the channel sink is ready, we poll the `control` and `input`
channels like before, as well as the new `ready_streams` `Stream`
(`ready_streams` is a `futures::Stream` that replaces the previous
`send_outbound()` function).
Most of the implementation remains unchanged, except the `handle_input`,
`handle_cell` and `handle_control` functions no longer send anything on
the `chan_sender` channel. Instead, they may do some (synchronous)
processing, and send instructions for the remaining work that needs to
be done (for example, for writing the cell to the `chan_sender`
channel). These instructions are handled at the end of `run_once()`,
and are encoded in the `RunOnceCmdInner` enum.
What this change does **not** do:
* the control channel *still* bypasses congestion control. We could
fix this by making the various reactor functions send the
`RunOnceCmdInner` commands to `run_once()` via a channel
(instead of returning them). This would enable the reactor to stop
reading the commands (except for handle `Sendme`, which would be
handled separately) if it's blocked on congestion control.
|
| |
|
|
|
|
| |
This is unfortunately necessary, because after the channel handshake, we
need to give the channel reactor a `StreamOps` handle to the underlying
stream.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Needed for cases where we wrap an object that implements `StreamOps` in
an external type, thereby losing access to the `StreamOps`
functionality. For example, during the channel handshake, we `.split()`
the stream that implements `StreamOps`, which leaves us with a
`SplitSink` and a `SplitStream`, neither of which implement `StreamOps`.
Getting a handle to the underlying object that implements `StreamOps`
(for example, a file handle) *before* the stream is `.split()` enables
us to use `StreamOps` to manipulate the underlying split stream.
This commit also introduces a special `UnsupportedStreamOpsHandle`,
which is a type that implements `StreamOps`, but always returns an
error. This type is meant to simplify error handling and usage, and is
meant to be used in cases where `StreamOps` is not supported. TODO: the
name of this type is pretty confusing (it's very similar to
`UnsupportedStreamOp`, which is an error type), and should probably be
renamed to something else (`NoOpStreamOpsHandle`,
`BrokenStreamOpsHandle`, `DummyStreamOpsHandle` come to mind...).
Note: this changes the `StreamOps` trait to be slightly different from
what I originally envisioned in !2660 and #1769
|
| |
|
|
| |
The 1.2.4 release is out, so we won't be needing these anymore.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Channel was a type that you could Clone that implicitly
its state. Now, Channel always appears as an Arc<Channel>.
This change has several benefits:
* It makes the relationship between Channel struct and the
underlying channel more clear.
* It enables Channel to participate in the RPC system,
where everything has to be an Arc<.>
* It enables us to have a Weak<Channel>, if we ever want to.
* It will let us move various members out of ChannelDetails.
We did this change a while ago with ClientCirc.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This serves three purposes:
* It removes the 'send a cell' method from the channel's public
API. Nothing outside of tor-proto should have to use this.
* It paves the way for giving each circuit a separate handle onto
the channel's send functionality. This will eventually let
the channel multiplex among circuits more intelligently.
* It prepares for the next commit, which will make Channel itself
universally Arc<.>ed.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Some of the `tor_circmgr::Error` variants will include the `UniqId` of the
corresponding circuit, so we'll need to be able to display it without the
`Circ ` prefix.
Part of #1297
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
While looking for differences, we found that C tor always
omits the flags and the hostname from a BEGIN message sent on an
onion service circuit. In torspec!179, we specified that behavior.
This patch brings arti into conformance.
Closes #1077.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Because dropping a `StreamTarget` causes the circuit reactor to send
an End, the previous do-nothing implementation of `discard()` wasn't
sufficient to cause the request to be ignored without sending an
End.
This commit modifies our "close pending stream" behavior to only
optionally send an End message. To avoid confusion, I'm using a new
`CloseStreamBehavior` enum rather than an `Option<End>`, since we
had previously used `None` in some cases to indicate a default
(misc) end message.
|
| |
|
|
|
|
| |
Now that every state-change function consumes the IncomingStream,
there is no longer any reason to keep track of an internal state
enum.
|
| |
|
|
| |
This will let avoid some copying inside our HSS code.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This function can be used to display a more user-friendly representation
of a `HopNum`. This will print hop numbers as 1-indexed values: #1,
#2, etc..
We will soon remove HopNum's Display implementation in favour of
`.display()`.
|
| |
|
|
| |
Closes #1010.
|
| |
|
|
|
|
|
|
|
|
| |
For consistency with the other `ClientCirc` APIs,
`ClientCirc::allow_stream_requests` now takes a `HopNum` argument. Upon
receiving an incoming stream request, the reactor now checks if the
request came from the hop specified in `allow_stream_requests` (and if
it came from a different hop, the circuit is closed).
Part of #1009
|
| |
|
|
| |
Closes #993
|
| |
|
|
| |
These functions only ever return `Bug` errors.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
received.
`ClientCirc::allow_stream_requests` is now `async` and waits until the
`AwaitIncomingStream` control message is processed by the reactor.
This guarantees that by the time the `allow_stream_requests` future
resolves, the reactor is ready to process BEGIN/BEGIN_DIR/RESOLVE cells.
Previously, the client tasks from allow_stream_requests tests had to
sleep before sending the BEGIN cell to give the reactor time to process
the `AwaitIncomingStream` control message (which tells the reactor to
expect incoming BEGIN/BEGIN_DIR/RESOLVE cells on the circuit).
Fixes #994
|
| |
|
|
|
|
|
|
|
|
|
| |
This will enable hidden services to send `RENDEZVOUS1` messages to the
`N`th hop of the circuit rather than the `N + 1`th virtual one (which
can only used after the client and service have completed the
introduction handshake).
This also deprecates `start_conversation_last_hop`.
Closes #959
|
| | |
|
| |
|
|
|
|
| |
`HopNum` will be used in `ClientCirc`'s public API when we refactor
`ClientCirc::start_conversation_last_hop` to use the provided hop rather
than always using the last one.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
