Also write some new accessor methods on the baseclass.
The longer term idea is to make the server itself only use the uint160
raw version for bitcoin addresses.
For now move the encodings (between that uint160 and human-readable) to
the utils library.
Instead of merging a small list into a bigger and bigger list,
write lots of small lists (20MB each or so) and then when we hit
the wanted final size, merge all of those into one.
In extreme cases we might end up going over the bounds of the internal
buffers, as such myConnection.send() may now throw.
I also cleaned up the ping design and made it a bit more strict.
Last I increased the amount of incoming data I can receive in one go,
this will make throughput higher.
as the number of applications grows it makes more sense to separate
the 'server' library from the actually reusable libraries.
To recap, the 'server' library is what we started with when importing
all the code from the hub. Slowly we are moving good code out that
is stand-alone and reusable.
The 'server' library has always been a catch-all and
ideally only the hub links it in (far future goal).
In line with this I move a list of files out of server
into the utils lib.
I choose 'utils' because all these are plain old data
objects that many crypto apps will find useful.
now in utils/primitives/
* CScript
* CPubKey
* CTransaction
* CBlock
* FastTransaction
* FastBlock
* CScript
streams.h is now in utils/streaming/
hash.h is now in utils/
The reason there are no standard library versions of lock-free
containers is because you want to always take full advantage of
the details in question.
In this case (read millions of times for each modification) it makes
no sense to use anything other than a standard container, but put in
a copy-on-write block. Simple and easy.
Replace the m_buckets unsorted map with a lock-free version
based on atomic pointers. (BucketMap)
remove the m_leafs and move those into the bucket struct.
Make the access to the jumptable transactional to avoid one big lock
over all datastructures.
On my threadripper 2990WX the entire 150GB BCH blockchain was
parsed and imported in under 3 hours.
During the BCH fork-off time we allowed the client to be started
as either BCH or BTC and as such there are several code-paths
that behave different based on this user setting.
We remove those as we no longer allow starting as BTC client.
This also removes the check for the min-block-size (rollback protection)
as this is accomplished by the checkpoints on the BCH chain.
As boost testlib is extremely IDE unfriendly, as well as human
unfriendly with lots of macros for basic C++ functions (like methods!!)
this is better for me.
But the real reason is that its just unstable. I get double deletes
on some releases of boost and I'm missing plain features that all
other test frameworks have.
For instance a QCOMPARE shows what is expected vs what we got. Boost
just fails.
In QTestLib I can mark a test as "expect fail" an idea that boost
tried and failed (can easily create false positives).
This change makes the limits be static variables, which means they are
only settable once for a process. The only usecase so far is to use much
smaller limits in testing situations.
TomZ