This log channel copies the log line and instantly returns to allow the
main codebase to not have an impact on logging speed.
Normal usage this isn't really relevant, but for cases where we want a
massive amount of logging for performance tuning the logging ends up
being a bottle-neck. Well, not logging but the output channel ends up
being a IO based bottleneck.
This log channel moves the IO based work to its own thread in order
to ensure that the main code works at full speed.
We reuse the NetworkManager lower level code in order to connect
to the Bitcoin P2P network.
This implements the basics for anyone wanting to be a player on
this network.
This improves the double spend proof orphans code.
Also add a DSProof log-category and lots of log lines to make
looking at a debug build much more fun.
The core APIs in Flowee are quite low-level and especially combining
results from multiple services becomes tedius, verbose and thus
error-prone.
For this reason I wrote a new SearchEngine and related classes which
allow one to create a single compound request, submit it to the engine and
get a callback when it is done.
For instance one can now create a request for a transaction by txid and the
system will split this into a txid-lookup and the actual fetch for the
transaction.
Enough callbacks and options exist to be able to add a lot more details
this way in a simple manner.
Move some methods about arguments from util.cpp to Logger.
This makes the logger more stand-alone and this avoids the
global defined in util.h (still to be fixed in future..)
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)
The old was based on levelDB which has scalability issues and stability
issues. (most often cited problem is corrupted database..)
This unspent output database I wrote is based on the idea that we need
never actually update any rows, which makes most old fashioned databases
a bad fit.
All we do is create rows and we forget rows. So lets design a DB to fit
that pattern.
* logs.conf now also found directly in the homedir if there is no
$HOME/.config dir
* default filename is now 'hub.log' instead of 'debug.log'
* logs.conf now also detects ALL as a keyword for section
* logs.conf now also supports 'option path [path]'
To allow configurability, don't give the whole 1000 sections a
real component, let them be a meta-group.
Also add the upcoming POS (point of sale) component.
The change signifies that the server is not just for admin purposes it
will become the preferred way for all subnet-local interactions.
Notice that we still have the JSON based RPC protocol as fallback.
tomFlowee
TomZ