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.
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.
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.
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