| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
| |
This appears to be a testing-only struct, so we can safely ignore
the warning.
|
| |
|
|
| |
We need to pass by value for the conflux case.
|
| |
|
|
| |
The function can return an error, but only if `conflux` is enabled.
|
| |
|
|
| |
With the latest rustc version, this now triggers a warning.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Addresses https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3077#note_3218281
|
| |
|
|
|
|
|
|
| |
For leaky pipe, we just need to ensure we don't accidentally reroute it
to the join point on the primary leg.
Partially addresses
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3077#note_3218281
|
| | |
|
| |
|
|
| |
This causes the test client to send a two SWITCH cells.
|
| |
|
|
|
|
|
|
|
|
| |
A `None` value signals to the conflux code to know to fall back on the
initial RTT of the circuit.
Without this change, the conflux switching logic is broken as we end up
staying on the leg with the best initial RTT forever (the other leg is
never picked, because its `ewma_rtt()` is stuck on `u32::MAX`, and never
updated as we never send on it).
|
| | |
|
| | |
|
| |
|
|
|
| |
If we're already on the best leg, we don't need to switch (even if the
other leg happens to have the same "best" RTT).
|
| |
|
|
|
|
|
|
|
| |
Previously, this failed to assert that the mock relays received all the
expected SWITCH cells.
As it turns out, the assertion currently fails, because the default
value for our estimated RTTs is no longer zero (as of !3074), so we no
longer unnecessarily switch legs as much as we used to.
|
| |
|
|
|
|
|
|
|
|
| |
The conflux client now sends data to the mock exit relay over both legs
(it SWITCHes legs at some point), which causes the test to fail
(because the two legs of the mock exit write the data racily to the same
`Vec`, without attempting to put it in the right order).
To work around the lack of handling of out-of-order cells at the mock
exit, we can just sort the received data to make sure we got it all.
|
| | |
|
| |
|
|
|
|
|
|
| |
Previously, if the primary leg was blocked on cc, the conflux set would
continue polling the stream map non-blocked leg, and send a
`CircuitCmd::Send` instructing the reactor to send a DATA cell on the
non-blocked leg. The reactor would then (wrongly) reroute the DATA cell
to the primary leg, in violation of congestion control.
|
| | |
|
| |
|
|
|
| |
This will enable us to trigger conflux leg switches at various points in
the transmission.
|
| |
|
|
| |
For consistency with `chan_tx`.
|
| | |
|
| |
|
|
|
| |
As opposed to passing the individual parts of `TestCircuitCtx` (I find
this slightly neater).
|
| |
|
|
| |
This is a mess. A future commit will make it slightly less horrible.
|
| |
|
|
|
|
|
| |
This fixes a problem which caused the test to stall waiting for a cell
(simply blocking on receiving a cell is wrong, because it's possible for
the other leg to have already completed the transfer; we need to be able
to bail upon receiving a completion notification from the other leg).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mutex prevents concurrent uses of
`MockRuntime::advance_until_stalled` (which are forbidden by the mock
runtime), enabling us to call this (and its functions that advance time)
more liberally in the future.
Note: the `multipath_stream` test is *still* broken, but slightly less
so. Now the only failure is "all futures blocked. waiting for the real
world? or deadlocked (waiting for each other) ?", which can be solved by
ensuring the mock exit tasks always exit: now that the mock client task
keeps the stream alive until it receives an END cell, we need to ensure
the exits tasks can complete their own, without relying on the client
to end the stream. This will be fixed in another commit.
|
| | |
|
| |
|
|
|
| |
This enables the new `read_until_end()` call in the mock client task to
complete (otherwise it will just hang, waiting for the stream to end).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now send the SENDMEs as per the client's expectations, using the
right tags. This makes the test less fragile and easier to extend.
Note: the `multipath_stream` test currently fails, because
the mock exit endpoint never actually sends an END, so the stream never
gets closed:
```
all futures blocked. waiting for the real world? or deadlocked (waiting for each other) ?
```
This will be fixed in a future commit.
|
| | |
|
| |
|
|
|
| |
We're about to use this in a conflux test, to get the mock exit to
reliably send valid SENDMEs to the client.
|
| |
|
|
|
|
|
| |
With this change, the `multipath_stream` conflux test fails, because the
mock exit endpoint never actually closes the stream.
This problem will be solved in a future commit.
|
| |
|
|
| |
I'm about to add a `recv_data` too.
|
| | |
|
| |
|
|
|
| |
This is currently only used for logging purposes, but we will soon need
the actual `UniqId` of the test circuit leg to query its CC state.
|
| | |
|
| |
|
|
| |
For clarity, and so we don't forget what these numbers mean.
|
| |
|
|
|
| |
I am about to add more fields to these, so I'm documenting the existing
ones so we don't get confused about what they represent.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
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]>
|
