Changed approach to handling of failed peer connection.
The algorithm looks as follows:
With every failed connection attempt, peer is ignored for consequently increased time interval. Initial delay is set to 1 and then doubled with failed connection. Once the calculated interval exceeds 1hr, peer is completely removed from the address book.
This approach provides enough time for the failed node to restore (also about 1hr), but if the issue persists, the peer is removed, so there are no stall records in the address book. This should eliminate issues with failed peers, which are restored functioning with another IP address.
Known issue:
If a peer has more than one address and one succeeds while others failed but not expired, failed addresses may remain stored. Such a "leftovers" will be cleared if peer will disconnect and then successfully reconnect after some time (longer than 1hr). Should not be an issue in practice.
Changed approach to handling of failed peer connection. The algorithm looks as follows:
With every failed connection attempt, peer is ignored for consequently increased time interval. Initial delay is set to 1 and then doubled with failed connection. Once the calculated interval exceeds 1hr, peer is completely removed from the address book.
This approach provides enough time for the failed node to restore (also about 1hr), but if the issue persists, the peer is removed, so there are no stall records in the address book. This should eliminate issues with failed peers, which are restored functioning with another IP address.
Known issue: