This implements the sendTransaction command using the async framework,
allowing clients to benefit from multi-core systems to process
transactions in parallel when being submitted to the Hub.
The current design of the API is that all questions are answered in-
order. This implies that handling of one connection will also just use
one thread.
If we want to improve performance of things like "sendTransaction" we
want an async option, which runs the action and generates the answer
when its done in a separate thread (a new one for each async-request).
This breaks the in-order reply sequence for clients and as such it
requires them to set a new header-option to enable this.
From now on, make sure that the minor always has at least 2 digits
which allows us to use string compare of versions even if we have
more than 9 releases in a year.
This is an overload of message() specifically meant to build
replies to incoming messages.
The behaviour changed here is that incoming messages with
headers other than "RequestId" now get copied to the outgoing
message by default.
This also includes a little blockchain of 114 blocks (the first 100 just
coinbase to reach coin-maturity) with transactions generated by the
txVulcano. So lots of outputs.
I adjusted the BlackBoxTest to load this data into any hub with ease.
The old algorithm could end up doubling the size every time it
ran out, which eventually consumes all memory.
This way we reset to the user-default size when useful and increase
only based on need.
This means that the programmer needs to make a better estimation on
maximum size of messages, but it avoids behavior similar to memory
leaks.
Double check our message-calculation is proper by checking the result.
Notice that asserts and logDebug both are turned off in release builds,
so this is just added to debug builds.
The command really only accepts IP addresses, but we use 'localhost' as
an exception to bind to loopback for ipv4 and ipv6 at the same time.
Also improve logging of errors and avoid failing to start the API
service if a bind address wasn't an IP.
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)
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
Add a filter option to allow clients to send addresses
and match outputs against those bitcoin addresses so
only transactions that spend those outputs match will
be incuded in the result.
Add a session state so clients can send a filter
and just reuse that filter in subsequent calls.
Demote the old RPC one to Legacy.
The old is still useful as it allows the 'verbose' version, but it uses
lots of deprecated tech and thus doesn't scale.
This service allows one to connect it and register any number of
bitcoin-addresses which will then cause any transaction or block
coming in the future lead the subscriber to get notified about
such events.
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.
TomZ