| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
| |
This basically converts everything to use the num_traits conversion
function, and explicitly panics on errors.
|
| |
|
|
|
|
| |
This pulls in num_traits (which is already a dependency for PoW) to
allow f64 casts that for reasons I do not understand are not implemented
via TryFrom in the standard library.
|
| |
|
|
|
| |
This should never happen, as the queue size is limited to well below
u32. However, it's still nicer not to use `as`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to divide a Duration by this, and Duration only supports
division by u32.
This is, in a sense, just pushing around where the overflow would
happen, (from the conversion in the suggested update to the increment
when a item is dequeued). However, this overflow is so unlikely to
happen (it would require more that 14 million requests per second) that
it does not seem worth slowing down the increment operation to try to
handle it.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Made with https://crates.io/crates/typos-cli
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This adds a error type for internal errors, and in error cases where we
previously panicked, returns a Result instead. The publisher then simply
doesn't publish the pow_params line and warns the user.
|
| |
|
|
|
| |
This shouldn't happen, but there's not a good reason to panic if it
does.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will allow us to more easily switch out the implementation of this
queue as is needed for PoW.
|
|
|
This adds PowManager, as described in doc/dev/notes/service-side-pow.md,
hooks it into IptManager and Publisher, and adds code to publish and
rotate seeds, and to keep a updated list of Verifier instances for
currently active seeds.
|
