-
Notifications
You must be signed in to change notification settings - Fork 960
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
[core/swarm] Refactor and extend configurable connection limits. #1848
Conversation
To better track different connection counts, permit configurable limits for these counts and make these available for inspection efficiently, introduce dedicated connection counters via a `ConnectionCounters` structure that is exposed on the API via the `NetworkInfo`. All connection or connection states that are counted in this way can also have effective configurable limits.
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.
Good catch on the iterator state mismatch!
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.
Looks good to me with the same remarks as Max on the naming.
I incorporated the naming suggestion(s) in 4e447e9 together with a bit of refinement for the configuration APIs:
The |
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.
Both the connection limiting as well as the general API improvements look good to me.
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Max Inden <mail@max-inden.de>
The initial motivation for the work in this PR is #1839. However, the PR goes a bit further than to just add a single counter to have a more streamlined API. Thus, in order to better track different connection counts and permit configurable limits for these counts and make these available for inspection in an efficient manner (i.e. without linear counting operations), I introduced dedicated connection counters via a
ConnectionCounters
structure maintained by the internal connection pool but exposed on the API via theNetworkInfo
. All connection states that are counted in this way can also have effective configurable limits.All limits are now configured through a
ConnectionLimits
structure. The new configurable limits areConnectionLimits::max_established_incoming
for limiting the number of concurrent established connections that were incoming.ConnectionLimits::max_established_outgoing
for limiting the number of concurrent established connections that were outgoing.A limit that has been removed because tracking the related counts efficiently would be a bit laborious and I don't think it is particularly useful is
NetworkConfig::set_outgoing_per_peer_limit()
Note that there are still the pre-existing
ConnectionLimits::max_incoming
andConnectionLimits::max_outgoing
which correspond to the two new configuration options above, just for pending connections. I also took the liberty to change the connection limits to useu32
instead ofusize
for their types, which seems more appropriate.Fixed panic in the
Peer
APIThe
Network::peer()
API allows to iterate mutably over the ongoing connection attempts viaDialingPeer::attempts()
, where eachDialingAttempt
can beabort()
ed during iteration. However, the iterator did not take into account the changes to the internal iteration offsets when elements are removed. This was discovered while extending the connection limit tests a bit and has been fixed now as a result.