where the UTXO allows you to find an output based on txid+output, the
spentoutput DB turns that around and allows you to find an input that
spends a certain output.
This also fits perfectly find into the UTXO database class, so this
creates a new dir "spent" which is filled as expected.
This adds all the header ints to chunked messages, solving the problem
of losing RequestId on roundtrips if the answer was too big.
Added a unit test for this "new" features.
This makes callbacks all use shared_from_this() in order to avoid
callbacks being done on deleted instances (thanks boost!).
Last, special case when the user doesn't connect but just sends messages
which caused a send of data, only to realize the connection wasn't open,
and then a connect.
This makes sure we immediately start a connect on queue of a message.
For service applications that bind to networks (currently
only indexer) this allows users to pass the address:
0.0.0.0
to bind to. The effect will be that we find all the network
interfaces in the system and bind to all of them.
Notice that we already had "localhost" as an alias to bind to both
v4 and v6 loopback interfaces.
This new feature depends on optional dependency QtNetwork.
Now everyone auto-connects to localhost unless passed the
option --connect=
Also make indexer find the logs.conf from the same dir as the
commandline passed config file.
This makes running it as a service more useful.
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)
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.
TomZ