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.
Write a changesSincePruning integer which has the following effects;
after a restart;
* We will do a prune faster and/or more often for nodes that are not
running very long stretches of time.
* We will skip pruning files that don't need it.
Context; pruning of the UTXO is throwing away already spent outputs
that are still in our dirty files.
When an indexer is in-sync it will stop actively asking for
new blocks, so the block updates (Hub saying they found a new block)
will then allow the indexer to keep up-to-date
This adds lots of little things;
* Add GetTransaction API call
* I refactored the GetBlock API a little to reuse code.
* a new 'Version' API call for the hub
* API for the logging manager, so we can set a default
setup with just C++-APIs
* various (usability) fixes in the FloweeServiceApplication
* Binding to localhost attempts to bind to both IPv4 and v6
* Print the actual transaction hex from indexer-cli (which really
is just a testing app)
I added some docs to bind() that handlers there should call
accept().
Also made sure that when nobody accepts a connection it actually
gets disconnected instead of just being ignored.
The main goal of this is to make sure that network services
implementations don't reuse one bufferpool for all their remotes as that
can cause threading issues.
One bufferpool per remote is now made easy.
Its not clear from my reading of the docs, but the std::sort version
that takes a struct actually makes a deep copy of the struct for each
sort. Which means that this usage is a really bad idea if you were
actually storing the data on this struct.
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.
Make sure that a NetworkConnection object (which owns the callbacks)
doesn't return from its destructor until the already scheduled callbacks
in another thread have been completed.
This avoids shutdown scenarios where we execute in a deleted
object.
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.
TomZ