Refuse connections from recent disconnects

[jan-ferdinand]

In order to reduce the potential connection flood, rapid re-connection attempts after a disconnect are ignored.

If node A decides to (gracefully) terminate the connection to some node B, then node A blocks any connection attempts from node B for some time. The cool-down time can be configured through the command-line interface's argument “reconnect_cooldown”. The argument is given in seconds. The default is 30 seconds.

This introduces a breaking change because the public enum ConnectionRefusedReason gets a new variant RecentlyDisconnected. This enum is now marked #[non_exhaustive] to prevent future variant additions from being breaking again.

This introduces a breaking change because the public structure NetworkingState gains a new, private field.

[jan-ferdinand]

@aszepieniec, @Sword-Smith, I'm struggling to create a test for the new feature. The various state variables and channels wielded by other tests pertaining to peer connection seem to require an intimate understanding of the inner workings of the various tasks (which I lack), and seem to come with varying amounts of implicit behavior (for which documentation is lacking).

I have pushed my best attempt so far in commit 847d1b1. Clearly, there are some fundamentals I don't understand. I'd be grateful for some assistance.

[aszepieniec]

This introduces a breaking change because the public enum ConnectionRefusedReason gets a new variant RecentlyDisconnected. This enum is now marked #[non_exhaustive] to prevent future variant additions from being breaking again.

I did not realize this change would be breaking, but it is. Let's avoid modifying existing messages and add new ones instead. (Actually, I'm assuming that new messages are simply ignored by old clients, but this assumption is worth verifying.)

[aszepieniec]

Actually, I'm assuming that new messages are simply ignored by old clients, but this assumption is worth verifying.

It sounds like any change to PeerMessage would be backwards-incompatible 🤦 So for the time being, we are not allowed to change this struct at all. We can speculate about how to get around this in issue #440 but that's probably out of scope for this PR, which about getting the internals to work.

[jan-ferdinand]

Clearly, there are some fundamentals I don't understand.

As far as I can tell, the problem is that the channel from_peer_to_main_tx gets closed after calling answer_peer_inner. This only seems to happen the second time answer_peer_inner is called. I think I need to keep this channel open somehow, or create an equivalent channel. I'd be grateful for some assistance.

[Sword-Smith]

I think you mention the wrong default value in the commit message. Otherwise LGTM.