| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Prop 340:
https://spec.torproject.org/proposals/340-packed-and-fragmented.html
This updates the decoding API to support multiple versions of the relay
cell encoding, including the new encoding proposed in prop340 that
supports relay message packing and fragmentation.
This commit doesn't actually add support for that new encoding yet.
|
| |
|
|
|
| |
For consistency with the terminology proposed in
https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
|
| |
|
|
|
|
|
| |
We never actually constructed these before, but now we enforce it at
the API level.
Part of #1269.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is pure renaming, done automatically with rust-analyzer.
Comment fixes and other cleanups will be in the subsequent commits.
We're doing this renaming because we need a name for
the combination of a `RelayMsg` and an `Option<StreamId>`
that we use when we have a `RelayMsg`
we intend to route to a given stream or circuit internally.
Previously we called this a `RelayCell`,
but that name was already somewhat inaccurate,
and will become _very_ inaccurate with the arrival of prop340,
which breaksthe 1:1 relationship between relay cells
and relay messages.
(If we didn't do this renaming now, we'd soon be making
the relationship between `UnparsedRelayCell`and `RelayCell`
many-to-many, which would be ridiculous and confusing.)
The `RelayMsgOuter` name is a placeholder:
We expect that we'll want to rename this type,
and may also want to rename `RelayMsg`,
and unify our vocabulary in other areas too.
But such a renaming will have to wait
for a larger discussion affecting the specifications,
so that we can use the same vocabulary everywhere.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Now that IncomingStream doesn't implement Drop, we can just
destructure it.
|
| |
|
|
|
| |
Since dropping a StreamTarget will send an End, we don't need
to call reject_internal in this case.
|
| |
|
|
|
|
|
|
|
| |
It turns out that we can make `IncomingStream::reject()` consume
self, thus making it impossible to hit the double-close error
from outside the `tor-proto` crate.
Also, we rename `StreamTarget::close()` to `close_pending()` to
better reflect its limited applicability.
|