| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This has fewer weird edge cases than RwLock does.
It might also be reasonable to make this a AtomicU32 (or AtomicEffort
which wraps AtomicU32), but that's slightly more complex, so I've opted
for a mutex for now.
|
| | |
| |
| |
| |
| |
| | |
This modifies the code to be more testable (making it generic over
RendRequest, getting the time from the runtime rather than
Instant::now(), etc) and adds some tests for the PoW control loop.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This will allow the PowManager to have a copy of RendRequestReceiver,
which is important to allow the PowManager update loop to control the
suggseted_effort updating.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This makes the suggested_effort value a Arc<RwLock<Effort>>, which is
shared between the PowManager (as a reader) and the RendRequestReceiver
(as a writer), since the RendRequestReceiver has the information needed
to update the suggested_effort value.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The updated PoW control loop in prop362 requires this data structure to
be double ended, which BinaryHeap is not. I benchmarked [email protected]
against BTreeSet on a synthetic benchmark based on what I expected
typical load to look like, and found that BTreeSet performed much
better. It is additionally in the standard library, and is maintained,
which no third-party double ended priority queue crate seems to be.
Given that, BTreeSet seems like a reasonable thing to build on, although
we should provide metrics on the performance of this queue so operators
can let us know if it seems to be a problem in real-world use.
|
| | |
| |
| |
| |
| |
| |
| | |
Since this will be used in a BTreeSet, we need to ensure that in
practice no two requests will be equal. Ordering by a combination of
effort and time received should be sufficient for this, and gives us the
behaviour we want.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Negotiate and use CGO.
Closes #1947 and #1945
See merge request tpo/core/arti!3069
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit prevents us from ever deciding that another relay
supports CGO, which prevents us from trying to negotiate it.
It also adds an assertion to make sure that we haven't tried to
negotiate it.
We can remove this once we're ready to have CGO turned on:
right now it's blocked on being able to negotiate CC.
I'm adding this so we can merge this branch (so that I can stop
rebasing it.)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We now take an enum describing whether we are doing no negotiation,
HsV3 negotiation, or full negotiation. This lets us do away with
the notions of default relay crypto, and of declaring post-facto
that no negotiation has occurred.
|
| | | |
| | |
| | |
| | |
| | | |
Instead call it compatible_with_cgo, which is what we actually
care about in this context.
|
| | | |
| | |
| | |
| | | |
Let's see if it works!
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Since these will be negotiated (or determined as part of negotiation)
they belong in HopSettings.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
`tor_llcrypto::pk::ed25519::PublicKey` is based on `ed25519_dalek::VerifyingKey`
and not `ed25519_dalek::SigningKey`.
|
| |/ / |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`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.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
tor-proto,tor-cell: Code refactoring and add support for sending XOFF messages
See merge request tpo/core/arti!3094
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
XON/XOFF flow control will want to know how many data bytes are queued
on a stream, so the new types track that.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It now performs some validation and can return a `Result`.
We perform validation here since different cell formats may have
different maximum data lengths in the future, and `UnparsedRelayMsg`
doesn't expose the cell format so it's difficult to perform this
validation at a higher layer.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This allows us to extend the command to implement different flow control
methods. We could add new command variants for new flow control methods
instead, but I think it makes sense to have them be a single command as
they will always have a stream ID / hop location in common. This also
helps us keep the flow control logic in one place.
|
| | | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The `Ord` impl of `OooRelayMsg` already "reverses" the seqno comparison,
which means previously we were double-reversing it (leading to the ooo
cell heap logic being broken in cases where its size was > 1).
Caught by the new conflux switch handling tests.
|
| | | | |
|
