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.
This fixes the logic that finds out it should resume an interrupted
process. The code had false positives in case of a message split over
multiple TCP frames.
The NetworkManager now has more mature flow-control which means that we
send our buffers more regularly and we delay parsing received data if the
sending takes too long.
The direct effect should be that creating of a large number of messages
in response to incoming messages is no longer a problem in many cases.
tomFlowee
TomZ