| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Since these will be negotiated (or determined as part of negotiation)
they belong in HopSettings.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The idea here is that the reactor builds an `XonXoffReaderCtrl` for the
new stream, and the `XonXoffReaderCtrl` can receive notifications from
the reactor's `StreamFlowControl`. The `XonXoffReaderCtrl` can be
combined with any `AsyncRead` to build a `XonXoffReader`, essentially
wrapping the `AsyncRead` with a type that handles XON/XOFF flow control.
Essentially, the reactor gives you a type that allows you to add
XON/XOFF flow control support to any `AsyncRead`.
We will add this `XonXoffReader` to the `DataReader` in a future commit.
|
| |
|
|
|
| |
Nothing actually causes an XON to be sent yet. But this adds the code so
that anything holding the `StreamTarget` can request to send an XON.
|
| |
|
|
|
|
|
|
| |
This allows us to extend the command to implement different flow control
methods. We could add new command variants for new flow control methods
instead, but I think it makes sense to have them be a single command as
they will always have a stream ID / hop location in common. This also
helps us keep the flow control logic in one place.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are some pros/cons to this change:
Pros:
1. The only remaining `await` in `StreamReceiver::recv` is for polling
the receiver, which means we can turn the `StreamReceiver` into a
`Stream` in a future commit.
2. We won't block the user from receiving messages while we wait for the
circuit reactor to receive our SENDME message and send it on the
outgoing channel.
3. The `StreamReceiver` doesn't really care if it can't send the SENDME.
There isn't anything it can do, the circuit hop can go away for
external reasons like a DESTROY message, and we still want to return
all queued messages to the user anyways.
Cons:
1. If the `StreamReceiver` sends a SENDME request to the circuit
reactor, and the circuit reactor fails to send the SENDME, there's no
good way for the reactor to communicate this back to the
`StreamReceiver`.
|
| |
|
|
|
|
|
|
|
|
|
| |
This requires some changes to the tor-proto crate to handle the inbound
TargetHop from the HS subsystem and then resolve it into a HopNum for a
single circuit.
It is expected that this will change again with Conflux to only use
HopLocation internally in a Tunnel and then use HopNum into a Circuit.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This is in the spirit of making everything going inbound the tor-proto
crate to use a TargetHop.
This becomes much easier for the HS subsystem as it only uses the last
hop for its conversation and setup.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Quick helper as within the tor-proto crate, we sometimes have to quickly
get a TargetHop.
This will come handy with the message handler used by the Conversation
object that the HS subsystem uses.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is about to be used outside of tor-proto. It is part of the work to
remove the use of HopNum outside tor-proto.
The rules are:
- Inbound requsest to the tor-proto crate, TargetHop must always be
used.
- Within tor-proto, TargetHop is resolved into a HopLocation which is
more precise and based on the tunnel circuit(s).
This is another piece that Conflux will require considering that a
Tunnel might have multiple circuits in the future.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Closes #1999
|
| |
|
|
|
|
| |
This type will help produce better logs (logging just the circuit ID
would make it impossible to correlate said circuit with the tunnel it
belongs to).
|
| |
|
|
|
|
|
|
|
|
| |
Currently, a tunnel is uniquely identified by the `UniqId` of the first
circuit added to the tunnel. This works, but the double-meaning of the
`UniqId` is bound to cause confusion in the future (because it blurs the
distinction between tunnels and circuits).
This introduces a new `TunnelId` type which will replace `UniqId` in the
tunnel reactor.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since v1 cells have a longer tag, they can fit less data into a
single cell. Ah well, that's the cost of improved security.
The code in data.rs is a little wonky, in that it currently requires
its buffer to be exactly the maximum size for a data cell. We have
a TODO about fixing that in the future, but for now I've moved it to
use a boxed slice rather than a boxed array.
Part of #1944.
|
| | |
|
| |
|
|
|
|
|
|
| |
This doesn't yet change the public API, it just begins the work of
plumbing these around throughout `ClientCirc`, `Reactor`, etc.
This can't be broken up into smaller commits without causing build
failures.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is mostly code motion + some visibility adjustments.
Moving all of these outside of `reactor` makes it easier to see which
parts are internal vs which are accessed by the reactor. It also helps
us enforce/audit invariants such as 'there should be no contention on
the `CircHop::map` mutex' (the stream map is now private to
`reactor::circuit`, and therefore nothing inside `reactor` will be
directly accessing it).
|
| | |
|
| | |
|
|
|
Move StreamTarget to the tunnel module and the circuit module.
From now on streams will be implemented on tunnels, not circuits.
This moves `StreamTarget` to the tunnel module. A future change will
replace `ClientCirc` with `ClientTunnel` inside `StreamTarget`.
This is mostly code motion, best reviewed with `--color-moved`.
Signed-off-by: David Goulet <[email protected]>
|
