-
-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: make the network listener more stable #5962
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
Can you explain this edge cases in more detail? Also please elaborate a bit more on why this config is brittle |
If set the value to The edge case I m referring to is if one connection is made and one connection is dropped simultaneously. So the moment listener stopped and listener started again. I opened a PR in |
// Instead, we stop listening when the number of connections is below the target peers | ||
// given that target peers and max peers have a reasonable gap between them and | ||
// target peers are always less than the max peers | ||
listenBelow: networkOpts.targetPeers ?? -Infinity, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this value need to default to -Infinity or 0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe both can work as connection count never gonna be below zero. But with the consistent approach of positive Infinity, I suggest to use the negative Infinity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-Infinity is dangerous because it means that once closeAbove is hit, the listener will never turn back on and we won't ever get inbound connections.
That was the intended behavior of setting both values high. I don't think that is brittle, and if it is, we just need to fix the underlying implementation. That said, its worth thinking about what kind of connection behavior we want, and viewing this PR on its own merits. |
As the underlying issue is addressed by libp2p/js-libp2p#2058, so closing this PR. |
Motivation
Make the network listener more stable.
Description
Steps to test or reproduce
Run all tests.