| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
Same as the client reactor, a message outside of our restricted set
leads to a reactor shutdown.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes the CircuitRx* based solely on the client circuit
message and moves it into the top level of the crate so all reactors can
use them.
The client reactor then upon receiving the message, it converts the
AnyChanMsg into a ClientCircChanMsg. On error, this leads to a shutdown
of the entire reactor due to a fatal error.
In order to pull this off, we added a CircuitAction::Shutdown that is
handled as a priority.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
This follows the move of the client specific object.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
| |
Without this, `tor-proto` doesn't compile if you enable the `relay`
feature but not `hs-service`.
|
| |
|
|
|
| |
This was all wrong, as mentioned in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3487#note_3296033
|
| | |
|
| |
|
|
|
| |
Since EXTEND is not used anymore, it's fine to handle it in our
catch-all branch for unrecognized/unsupported cells.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This TODO was copied over from the client reactor, but it doesn't make
any sense here (we don't yet handle control messages in the backward
reactor).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Initially I wanted to turn `msg_streamid()` into a method on
`UnparsedRelayMsg`, but I ultimately decided against it, because it
feels like it doesn't belong there (even though intuitively, I would've
expected it to handle the mismatch between stream ID and cell command
internally). This is because all the `UnparsedRelayMsg` methods return
`tor_bytes::Result`, and do not actually do any validation beyond some
length checks on the various fields.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The relay reactor is now able to handle incoming stream requests (i.e.
cells that open streams). It currently only supports DATA stream
requests (BEGIN); support for other stream types (BEGIN_DIR, RESOLVE)
will be added later.
`Reactor::new()` now returns the futures::Stream of Tor streams, alongside
the `Reactor` and `RelayCirc` handle. Whoever calls `Reactor::new()` is
responsible for passing the stream of streams over to the task that is
meant to handle it ("handle" in this case means either rejecting the
stream with a given `END` cell, or accepting it and forwarding the
connection between it and the corresponding application stream).
IMPORTANT: the above is a bit half-baked! Next on my TODO list is is to
iron out the details of how/where this will actually be handled.
I am also a bit unsure about the API here: I think it might've been
nicer to give the user the ability to obtain this `futures::Stream` from
`RelayCirc`, which is, after all, a handle to the reactor?
Also on my short-term TODO list is to figure out how conflux will affect
this API and usage.
And there is another wrinkle here: for incoming DATA stream requests,
the handler will need to produce a resulting `DataStream`, which is not
yet fully implementation-agnostic (it wraps a `ClientDataStreamCtrl`).
This too will be handled in a separate MR.
|
| |
|
|
| |
These will need to be handled soon
|
| |
|
|
|
| |
This is needed because we will soon have another callsite for it, which
will need to pass `AnyRelayMsgOuter`.
|
| | |
|
| |
|
|
|
|
|
| |
I've made `run()` more similar to its client circuit reactor counterpart
(I think the error reporting will be better, and if we ever need to make
the reactor public, it will be easier this way because now `run()`
doesn't expose the crate-private `ReactorError` type).
|
| |
|
|
|
| |
This is already namespaced under the `relay` module so the `Relay`
prefix is redundant.
|
| |
|
|
| |
This will be needed soon.
|
| |
|
|
|
|
|
| |
This MPSC channel now has zero buffering, because if the backward
reactor can't send the cell, the forward reactor must immediately stop
reading from its inputs (note that the backward reactor's Tor channel
towards the client *does* have a buffering layer).
|
| |
|
|
|
| |
There are other types of messages (like circuit-level SENDMEs) that need
to be handled in the backward reactor too.
|
| |
|
|
|
| |
We will soon need a handle to the runtime in BackwardReactor (we need a
time provider to call `note_sendme_received()`).
|
| |
|
|
|
| |
We need to avoid reading from all of these if the chan_sender isn't
ready, because otherwise we can't provide backpressure.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The backward reactor needs this for handling padding (because it may
need to e.g. put the chan sender in a blocked state).
Note that `CircuitCellSender` has an underlying
`SometimesUnboundedSink`, so from now on we must be very careful and
avoid writing to the `chan_sender` if it's not ready (because otherwise
we can end up buffering unboundedly). The next commit will add some
extra checks against reading from futures::Streams that might cause us
to write to the `chan_sender` sink (futures::Sink).
|
| |
|
|
|
|
| |
Rewriting the code this way reduces the indentation level for the
"recognized cell" case (which is not yet implemented, but will be very
soon), thereby making it more readable.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The UnverifiedChannel::finish() was split in previous commit so this
adds the support for sending the right NETINFO cell instead of the
client specific one.
Added more TODOs for followup commits.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
| |
Add the finish() function that for now simply calls the generic
finish(). There is a bunch of TODO in the code in this commit explaining
why we haven't made the implementation relay specific just yet.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commits takes out the relay specific code out of UnverifiedChannel
and puts it in UnverifiedRelayChannel.
In order to pull this off, we added some fiels to the VerifiedChannel
struct so the relay code get back generated data from the
UnverifiedChannel::check() in order to do its validation work and yield
a VerifiedRelayChannel.
This also lead to a cleanup of expect() and ChannelType::is_initiator().
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The new UnverifiedRelayChannel and VerifiedRelayChannel struct are added
to decouple the client code and put the relay component in its module.
Both objects hold the to become generic object that both client and
relay will use to create a channel.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't really need this channel here, because we already have control
and command channels for checking if the reactor task is still alive.
|
| |
|
|
|
|
|
|
|
| |
While this is technically a "reactor handle", I think RelayCirc sounds
better, because this is essentially our only public API for interacting
with a relay circuit (it will be used outside of tor-proto).
(This would also be consistent with our existing ClientCirc
client-side terminology).
|
| |
|
|
| |
This will soon become `pub`, so I am factoring it out of `reactor.rs`.
|
| |
|
|
|
|
|
|
| |
BackwardReactor is an implementation detail, so it shouldn't really be
mentioned in the soon-to-be-public-facing docs.
And besides, the control messages are no longer handled by the
BackwardReactor.
|
| |
|
|
| |
We replaced TunnelId with UniqId in the relay code a while ago.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is only done if we kept the AUTH_CHALLENGE cell and we have relay
identities. In other words, this is only when the UnverifiedChannel was
created from a RelayInitiatorHandshake.
Note: The check_internal() function is too large and should be
refactored in smaller pieces.
Note: It is also likely that we need to split UnverifiedChannel and
VerifiedChannel as it is getting client or relay members. Not great.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The client and relay channel builder don't share anything and return
different objects hence the seperation.
Furthermore, this seperation avoids having the client ChanMgr ability to
launch relay channels.
Signed-off-by: David Goulet <[email protected]>
|
