| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
The `CircHopSyncView` is now the view of a hop, not of the whole
circuit.
|
| |
|
|
| |
And update the docs
|
| |
|
| |
Co-authored-by: carti-it <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As near as I can tell, there are only three ways that the sender
corresponding to this rx can be dropped:
- `StreamMap::terminate` because the stream object itself was
dropped. (But see #2323.)
- `StreamMap::close_stream` because an END message or similar
has been received. (But see #2322.)
- The `StreamMap` has been dropped.
The first two cases are already handled, and AFAICT the third can
only happen when the circuit hop closes. That makes
`CircuitClosed` the appropriate error here, not `StreamProto`.
Part of a fix for #2304.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
While we still re-export StreamReceiver from the client module, I want
to avoid importing it from there in the implementation-agnostic modules,
just to make it clearer we're not using client-specific types.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The previous "incoming" terminology was rather ambiguous.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337
|
| |
|
|
|
|
|
| |
This will be used by relays too (for validating incoming messages on
streams).
This is just code motion, so it's best reviewed with `--color-moved`.
|
| |
|
|
|
| |
The CmdChecker will be used by relays too, so I am moving it to the
shared `stream` module.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
`StreamFlowCtrl` is no longer accessible via `tor_proto::client`, so I
had to update one of the (doc) imports with its new path
Also, I had to change a couple of imports to use `DataWriter` and
`DataStream` from `crate::client::stream` instead of
`crate::client::stream::data`, because the latter is not visible from
`flow_ctrl` anymore.
|
| | |
|
| |
|
|
| |
This will be used by exits too, so I am moving it out of `client`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
|
| | |
|
| |
|
|
|
|
| |
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In order to pull this off, some client => tunnel renaming needed to
happen including the comments.
The send_raw_msg() is an experimental and expert mode method that any
tunnel should have access to in order to be able to send whatever
message in whatever tunnel type.
No behavior changes.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`DataReader` -> `DataReaderInner`
`DataReaderNew` -> `DataReader`
This means that the `DataReader` now supports XON/XOFF flow control
using the `XonXoffReader`.
This means that it can receive requests for a new drain rate from the
reactor, and can send the new drain rate to the reactor once there is no
more stream data queued.
|
| |
|
|
| |
This will later become `DataReader`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
XON/XOFF flow control will want to know how many data bytes are queued
on a stream, so the new types track that.
|
| |
|
|
|
|
| |
As we continue adding more functionality to streams like flow control,
we'll have more objects to pass around. This tries to group them
together.
|
| |
|
|
|
|
|
|
| |
The plan is to use `StreamSendFlowControl` (now `StreamFlowControl`) for
both outgoing and incoming directions, so a name change is needed.
This also updates some comments, and renames some related struct fields
that have the word "send" in them.
|
| |
|
|
|
| |
I don't see any further changes being needed for these types, and it
simplifies a lot of future code in tor-proto that uses these types.
|
| |\
| |
| |
| |
| | |
tor-proto: Handle incoming XON/XOFF messages
See merge request tpo/core/arti!3054
|
| | | |
|
| | | |
|
| | | |
|
