A connection that is 'shutdown' now ensures one more time we'll call
onDisconnected() (is it was..) allowing the application level logic to
get notified and avoid memory leaks.
When the user-layer triggers a re-connect instead of waiting for the
layer to re-connect then we should avoid doing work twice.
This also avoids a reconnect in some cases.
As we moved most of the creation of a BufferPool to be via the
Streaming::pool() method, which uses a thread-local, it makes sense
to start cleaning up the design and make it more modern C++.
The above mentioned method would return a reference and you'd see
loads of places use `auto &pool =` which is less than ideal.
As the number of places where we actually instantiate a BufferPool
goes down, the usage of some sort of smart pointer makes more sense.
This now makes all APIs use BufferPool be wrapped in a shared_ptr.
Avoid massive connect storm.
Using the network manager based logger we got into a fun situation where
logging to a remote host caused us to connect and fail, which caused us
to log this failed which made us try to connect and .. etc.
The server always sends pongs in response to our pings, but we assumed
that the underlying OS would close a connection when the other side
isn't replying (ACKs).
Now we take this responsibility in the code and when no pongs are
registered we also close and re-establish the connection.
This additionally shortens the ping time to 30 seconds and the timeout
to 90 seconds.
The first bunch of times we want to reconnect much faster so we have less
downtime and faster response.
After a while it goes up to a slower timeout in order to not overload
logs and other such.
Avoid just appending the portnumber with a colon as that does not help
readability on ipv6 type addresses.
This now neatly adds the square brackets as needed.
For native connections we ping in order to disconnect stale connections.
This ensures that pings are sent more agressive, via the priority queue,
and we delay the disconnect to 150s.
So, pings more agressive, disconnects less agressive.
This introduces several options for public node operators to limit their
nodes usage by 3rd parties, this is aimed at usage of resource-hungry
areas.
We allow limiting the amount of connections any single IP can keep open
with us.
We limit the amount of reconnects we allow in a short number of seconds.
We allow limiting the number of addresses (or scriptHashes) a peer can
register for the node to scan.
The last one is for both the addressMonitorService as well as for the
getBlock filters.
For node operators these items become available using command line
options or config-file options. By default these limits are unlimited as
we assume default usage to be private.
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.
tomFlowee
TomZ