| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
Now that we no longer need to store a future, there's no need for this
state since we're never pending waiting for a future to complete.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This uses just a placeholder `Empty` stream for config updates.
|
| |
|
|
|
|
| |
We want the tokio trait to call into the futures trait, rather than
having each trait duplicate the logic of calling into the inner writer.
This is less error-prone.
|
| | |
|
| |
|
|
| |
The user now sets a constant amount of bytes to wait for.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Unfortunately the git diff thinks I moved the struct, but I really only
moved the comment.
|
| |
|
|
|
| |
`DataWriter` -> `DataWriterInner`
`DataWriterNew` -> `DataWriter`
|
| | |
|
| |
|
|
|
|
|
| |
This doesn't do anything yet, so is effectively like not having stream
flow control.
This should be implemented as part of arti#534.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 will let us actually _send_ messages in the right format.
This approach is not ideal for packed/fragmented messages;
they will need a separate RelayCellEncoder.
part of #1944.
|
| | |
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
| |
Co-authored-by: Ian Jackson <[email protected]>
|
| |
|
|
|
|
|
| |
Also, use static_assertions to enforce that that they
_stay_ Send+Sync.
Closes #1859.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
| |
Reducing `ClientCirc` proliferation will make our lives easier when
implementing !2790.
|
| |
|
|
|
|
|
|
| |
This method is experimental, so no semver note is needed.
It is redundant with `client_stream_ctrl()?.circuit()?`.
(The name and the unconditional return type of this method
are probably an error.)
|
| |
|
|
|
| |
Since these return a client-specific type,
they need a client-specific name before we can stabilize them for RPC.
|
| |
|
|
|
|
|
| |
Semantically, the new name matches the behavior much better.
(A stream could well count as open if we had sent a RESOLVE but not
received a RESOLVED, so we might someday want to have an `is_open`
defined for _all_ streams, not just data streams.)
|
| |
|
|
|
|
| |
The API for this type, and the fact that it implements
ClientStreamCtrl unconditionally, means that it is only for client
DataStreams.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It is official, congestion control is now used at this commit by the
circuit reactor making circuit/sendme.rs unused. Will be removed with
another commit.
Related #534
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
|
| |
Promote the associated comments.
As suggested here:
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2560#note_3097188
|
| |
|
|
|
|
|
|
|
| |
The DataStream is sometimes disassembled, eg by split. When that
happens, the StreamAccount would be dropped - and that was the only
strong reference.
Put a StreamAccount in each of the pieces, instead of just in the
combined DataStream struct.
|
| |
|
|
|
|
|
|
|
| |
We need the mq account for the stream not to collapse. The
ResolveStream object needs to contain a strong reference to it.
Have begin_stream_impl return the StreamAccount, rather than taking it
as a parameter. That makes this bug a little more obvious. It also
centralises the StreamAccount creation.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This will make it easier to change their types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| |
|
|
|
| |
From
<https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2340#note_3062531>
|
| |
|
|
|
|
| |
Encapsulate flow-control into a separate object that partially abstracts
away the difference between window-based (legacy) flow control and
xon-based (prop324) flow control.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In particular, clarify that dropping the DataWriter on its own does
nothing unless the DataReader is also dropped.
Related to #1368.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had a bug where `<DataWriter as AsyncWrite>::close`
(or `shutdown` in tokio-land) would not actually have any effect.
It _would_ drop the `StreamTarget` held by the `DataWriter`, but
since the `DataReader` also held a `StreamTarget`, the
MPSC channel would not get closed, and the circuit reactor would
not realize that the stream wanted to shut down.
Now we use `mpsc::Sender::close_channel` to make our closes
effectual.
Closes #1368.
Additionally, we fix a bug where `poll_close()` never actually did
anything if the buffer had nothing in it when it was called.
Previously, `poll_flush_impl()` would exit immediately if it had no
data to flush. That isn't what we want when we are closing!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
No actual bug here, just technical debt:
For `SendWindow`s, our tag system already ensured that we rejected
any SENDME that didn't correspond to an appropriate drain. Still,
it doesn't hurt to check.
For `RecvWindow`s, it would have been a protocol violation if we
ever did this, but it makes sense to make it an internal error if we
try.
Part of #1383.
|
| | |
|
| | |
|
| |
|
|
| |
(Doing this to prevent us having two structs with the same name.)
|
| |
|
|
|
|
|
| |
Based on designs in #1124.
Note that there is a TODO here about a hack I had to do to appease
the borrow checker.
|