Handle connection better: make connectd know which peers are important #7630
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustyrussell
added
the
Highlight - Stability and Security
It's now trivial for us to do this ourselves, since we have gossmap. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Let lightningd feed us hints to try first, but we can extract the addresses from node_announcement messages ourselves. (Lightningd used to ask gossipd on our behalf: this is far simpler!) One side effect of this is that we don't hand back address hints given to us by lightningd: it would use these again for reconnecting. This is breaks test_sendpay_grouping, so we disable it temporarily. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Once connectd is controlling reconnections, it'll need these. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…not just state. We're going to use this to ask if there are any channels which make it important to reconnect to the peer. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we connected out, remember that address. We always remember the last address, but that may be an incoming address. This is explicitly the last outgoing address which worked. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is more useful than the last address, which may be it connecting to us. And use it when we restore it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than have lightningd call us repeatedly to try to connect, have it tell us what peers are transient and aren't, and connectd will automatically try to maintain that connection. There's a new "downgrade_peer" message to tell it a peer is now transient: to make it non-transient we simply tell connectd to connect as a non-transient. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Changed: `connectd` now handles maintaining/reconnecting to important peers, and we remember the last successful address we connected to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The important flag replaces it, and now we can be more intelligent about eviction in overload. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We wait until a connection fails, or a subd is connected to the peer, before letting another one through. This should prevent us from overwhelming lightningd on large nodes, but unlike the previous back-off, it's based on how fast lightningd is, not an arbitrary time. We also let one through each second, in case we're connecting to many, but not doing anything but gossip (e.g. 100 explicit connect commands). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Changed: Reconnecting to peers at startup should be significantly faster (dependent on machine speed).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell
force-pushed
the
guilt/ccan-io-scale
branch
from
f3ff208
to
153bbe1
Compare
rustyrussell
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This series changes connectd to maintain reconnections, rather than the rather convoluted logic we had before. lightningd simply tells it which peers are "important", based on which peers have channels. We also are smarter about saving the last known address, if we have a successfully established an outgoing connection previously.
This lets connectd be smarter in overload, too, when it needs to select a peer to evict. And it's a chance to update our "startup" logic which tried to space out connections: we keep 10 in flight now, and wait until lightingd has forked off a subdaemon before adding more (though we always let through one a second, for corner cases).
These changes should help large nodes.