| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Improve descriptions of rejected relays: omit "rejected 0/X"
Closes #2006
See merge request tpo/core/arti!3072
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now instead of saying "rejected 0/40 as not usable as middle relay;
28/40 as in same family as already selected", we say "rejected 28/40
as in same family as already selected".
Closes #2006.
|
| | | | |
| | | |
| | | |
| | | | |
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]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In order for this to work, a last_target_hop() function is added to
ClientCirc in order to return a precise hop location as a TargetHop of
the last hop.
This is needed because in the HS subsystem, we need such value in order
to get a location on the last physical hop before adding the virtual
hop.
The RDV1 cell is sent to that last target hop while the
allow_stream_request() is done on the virtual target hop.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is in the spirit of making everything going inbound the tor-proto
crate to use a TargetHop.
This becomes much easier for the HS subsystem as it only uses the last
hop for its conversation and setup.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Quick helper as within the tor-proto crate, we sometimes have to quickly
get a TargetHop.
This will come handy with the message handler used by the Conversation
object that the HS subsystem uses.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This allows us to use TargetHop instead of HopNum but also to get one
step closer to not depend on a mutable state.
We prefer resolving a TargetHop within the Reactor object in order to
use the circuit list instead of the MutableState path.
The HS service subsystem is modified to use this modified function that
is now async and uses a TargetHop.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is about to be used outside of tor-proto. It is part of the work to
remove the use of HopNum outside tor-proto.
The rules are:
- Inbound requsest to the tor-proto crate, TargetHop must always be
used.
- Within tor-proto, TargetHop is resolved into a HopLocation which is
more precise and based on the tunnel circuit(s).
This is another piece that Conflux will require considering that a
Tunnel might have multiple circuits in the future.
Signed-off-by: David Goulet <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Reactor has two functions to resolve both TargetHop into a
HopLocation and then a HopLocation into a (UniqId, HopNum).
This commit simply adds a helper that does both but returns an Option
instead of a Result as it will be used by the reactor command handler
and more in future conflux commits.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-proto: Add `Notify{Sender,Receiver}` channel
See merge request tpo/core/arti!3066
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
An async notification channel.
This uses `postage::watch::{Sender,Receiver}` internally.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
tor-proto: Give Circuit a handle to the DynTimeProvider.
See merge request tpo/core/arti!3063
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will enable us to replace the calls to `Instant::now()` with
`DynTimeProvider::now()` throughout the RTT estimator.
This gives us the ability to mock the time, and test that conflux
leg switching occurs as expected.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The expanded expression makes it easier to see that
`can_crosscheck_with_current_estimate()` can never return `true` if
`self.ewma_rtt` is `None`, and that the `expect()` from
`is_clock_stalled()` cannot panic.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `RttEstimator` now uses `None` to represent not-yet-measured RTTs.
Previously, all the measured RTTs defaulted to 0, in contradiction with
the `RttEstimator::{min,ewma}_rtt_usec()` docs, which state that both
functions are supposed to return `u32::MAX` if there is no estimate.
Closes #2049
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | | |
tor-cell: Fix incorrect XON/XOFF cell command integers
See merge request tpo/core/arti!3061
|
| | | | | | | |
|
| | |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- Made an equality assertion between two constants compile-time, resolving a
TODO.
Signed-off-by: hashcatHitman <[email protected]>
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | | |
tor-proto: Typo fixes in conflux docs and comments
See merge request tpo/core/arti!3065
|
| | | | | | |
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Add logging for possibly-bad net params
See merge request tpo/core/arti!3043
|