Move the creation of the ping message to the constructor (from the
connection-established method) so we are certain it gets done exactly
once.
Also avoid putting default (invalid) values in the hashmap.
Upgrade the code to check not just if the compiler supports, but
try the actual system too.
Also add a new cmake option 'reproductable_builds' which, when set
to true, will not include any optimized hashing algorithms.
Upgrade the code to check not just if the compiler supports, but
try the actual system too.
Also add a new cmake option 'reproductable_builds' which, when set
to true, will not include any optimized hashing algorithms.
This avoids an internal error from failing one block due
to a perceived missing input while the block may be fine
but other issues need looking at (for instance disk errors).
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.
Make things more foolproof by having similar items in different namespaces
use the same number.
Remove APIs for the wallet as that is not a shipped component of the Hub
when we get a hash from the JSON wrapped RPC interface it is a string
and it is in reverse order.
This makes sure that the generate() will create the same
hash as other parts of the API.
Checking if my database file is full can not be assumed to only happen
on end-of-block if blocks get really large.
I'm taking a small performance hit to check this on insert and
flushSomeNodesToDisk on a more regular basis.
for internal purposes the network manager used std::list instances
for things that essentially were FIFO queues.
With high volume of packages being sent this causes a large overhead
and even a crash or two.
So I replaced them with ringbuffers which means that the normal
sending
of data will remove a large selection of mem allocations.
TomZ