| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| | |
memquota: Fix account lifetime bugs, and arrange to test mq in shadow
See merge request tpo/core/arti!2560
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Now that it doesn't call CircuitAccount::new() it has no error paths,
and clippy demands we remove the Result, so it must once again become
infallible.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We foolishly made *two* CircuitAccounts, one of which gets immediately
dropped. But we need to hold onto the account somewhere, because an
mq_queue doesn't keep the account alive.
Otherwise everything breaks when mq tracking is enabled.
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Use memquota queue for channel->circuit RX data
Closes #1682
See merge request tpo/core/arti!2518
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Fixes #1682.
(This involves some noise in the tests.)
|
| | |
| |
| |
| |
| | |
This is neater and will make changing the type (in a moment) less
noisy.
|
| |/
|
|
| |
Fixes: #628
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Change the typss of StreamMpscSender and StreamMpscReceiver.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
tor-proto: Introduce type aliases for some queues
See merge request tpo/core/arti!2484
|
| | | |
|
| | |
| |
| |
| | |
This will make it easier to change their types.
|
| |/
|
|
| |
This prepares us to change the types of these queues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
There is now (sendme-style) flow control, and some fairness
(via round robin scheduling of streams).
|
| |
|
|
|
|
| |
There is a mutex for some of the "mutable state", but the reactor only
needs to lock it when adding a hop. It's not needed "to process a cell"
or when streams send. Probably not worth calling out here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This commit fixes a bug in the `ClientCirc::extend_ntor` function, which
currently returns a `Error::MissingId(Ed25519)` in the case that no RSA
identity has been found in the accompanying channel target.
This behavior is obviously wrong, because a missing RSA identity should
yield a `Error::MissingId(Rsa)`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This test verifies that when we invoke the code to close a stream,
an END message is actually sent.
The test comes in two versions:
* `drop_stream` closes the stream by dropping it. It currently
passes on main.
* `close_stream` closes the stream by running `AsyncWriteExt::close`
on the writer. It is a regression test for #1368. It currently
fails on main.
|
| |
|
|
|
|
|
| |
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!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Channel was a type that you could Clone that implicitly
its state. Now, Channel always appears as an Arc<Channel>.
This change has several benefits:
* It makes the relationship between Channel struct and the
underlying channel more clear.
* It enables Channel to participate in the RPC system,
where everything has to be an Arc<.>
* It enables us to have a Weak<Channel>, if we ever want to.
* It will let us move various members out of ChannelDetails.
We did this change a while ago with ClientCirc.
|
| | |
|
| | |
|
| |
|
|
| |
(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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The key insights here are:
- That relay cell format and crypto protocols aren't orthogonal:
Once we have GCO, it will require V1.
- That we only need the actual functions for layer construction to
be generic; we don't need to proliferate generic parameters
everywhere.
- That the circuit::handshake module already does most of what we
want.
|
| |
|
|
|
|
| |
This lets us paramaterize types and functions by a particular relay cell
format. We use this e.g. to statically parameterize the cell crypto
functions, thereby removing some run-time branching in the hot path.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
`tor_circmgr::Error::Protocol` will soon include an optional `UniqId`.
Since `Protocol` errors can be caused by pending circuits, we need to be
able to peek at their `UniqId`.
Part of #1297
|
| |\
| |
| |
| |
| |
| |
| | |
Several clean-ups around failures in incoming stream request handlers.
Closes #1190, #1189, and #1188
See merge request tpo/core/arti!1892
|