We now query more information initially when synching, which can be
useful.
We also deal with initial block download by retrying every minute
and other miscellany
When reading data from bitcoind, we can assume the hex data it gives us
is good and there is no need to validate on a per-character basis.
Thus, we use ParseHexFast to shave off cpu cycles (it's like 6x faster
than Qt's fromHex()).
This, along with the Util::ToHexFast() (which is 60% faster than
QByteArray::toHex()), will be used in performance critical code.
This is more complex than what we had before -- but is more concurrent
and is more production-ready -- it can deal with failures better and now
we also poll bitcoind for new headers.
Still probably can be optimized somehwat -- but getting there!
Set maxcur to 16, spinning up 3 bitcoind threads.
Seems to have brought header synch down from 170s to 71s on my mainnet
node here locally. Not bad!
Also fixed a bug where selecting bitcoind nodes was failing if >2 nodes.
And added some test code in Controller to use the scheme.
It's very asynchronous. Needs some tuning long term to see how it deals
with load and perhaps throttle the requests if we know bitcoind is under
load.
But for right now, for testing, it should work ok.
Also in this commit small nits, plus bugfix to RPC::Message factory
methods (I forgot to populate some instance properties when constructing
the objects).
Additionally, we were registering the qMetaType wrong for RPC::Message
and RPC::Message::Id (this has been fixed).
Playing with lambdas. Detects when bitcoind goes down. Initial code --
can put hooks in the detection for eg. stopping block processing or
starting it, etc.
Controller will manage BitcoinD and perhaps synching to bitcoind. It can
"see" all the servers as well as bitcoind.
Also refactored things a little bit and added some more startup sanity
checks.
- It's still a little more restrictive than the spec allows -- doesn't
like non-positive-int 'id'
- We not made the shuffle.spec status report back 'notifications' to the
client rather than repeated 'result' messages (as those would be out of
spec). The first response to a 'shuffle.spec' request is either
result="pending", result="accepted", or an error response
- Subsequent shuffle.spec status changes come as a method notification
for "shuffle.spec" with params=["accepted"] or params=["some error
message"]
Overall I think our bare bones JSON-RPC will at least not break now as
interop with other impls.
We are like 50% there to milestone 1. Next, implement shuffle logic,
python test client, and tx building/verification.
Who am I kidding.. we are still pretty far away. :)
- Util::RunInThread to run a lambda in a thread
- App exit handling cleanup
- EXMgr uses an id for clients now
- EXMgr keeps track of lagging clients
- EXMgr more aggressive with reconnects if no valid exclients
- Nits and refactorings and misc. cleanup
- Made the stale timeout be 2 mins now
- Check clients runs every 1 minute
- Added 'Controller' ABC which EXMgr is one of and the TcpServer will be
another.
