| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.37.0
done
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
We know from the start that this is 32 bytes so no reason to hard fail
if not, just propagate the right type from the start.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
| |
Move the client specific code into VerifiedClientChannel as in sending
the NETINFO cell. The rest is pretty much boiler plate to build a
channel reactor.
The relay finish() code is coming in a followup commit.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
By changing the connect() returned object we therefore officially make
VerifiedChannel and UnverifiedChannel crate only objects.
Thus, this commit changes visibility on most things.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the UnverifiedClientChannel and VerifiedClientChannel
mirroring the relay API for channels.
It plainly uses the generic object underneath as for now those objects
are client only.
Followup commits will make things more client specific.
No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
| |
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]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The relay reactor needs the cc state to be shared between the inbound
and outbound components (i.e. the forward and backward reactors), so we
need to put the cc state behind a mutex.
There will never be any contention on this mutex in the client impl,
because the client reactor doesn't split the `CircHop` into
`CircHopInbound` and `CircHopOutbound`.
In the future, we should work on trying to reduce the number of locks in
the `CircHop` states.
|
| | |
|
| |
|
|
| |
These will be soon used by relays too.
|
| | |
|
| |
|
|
|
| |
The Inbound/Outbound CircHop states will be used in the relay reactor,
so it's helpful to move some of the `CircHop` impl there.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will be used by relays too, once we modify it to make the `HopNum`
optional.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Unlike the client reactor, the relay reactor uses these components in
separate tasks. Splitting `CircHop` this way enables us to reuse its
parts instead of duplicating them in the relay impl.
Eventually, I'd like us to rewrite the client reactor to follow a
similar pattern.
|
| | |
|
| | |
|
| | |
|
| | |
|
