You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the network gets larger, bootstrap nodes can exceed the default inbound connection limit, and drop new connections. Currently we resolve this issue by increasing the connection limits on the command line, so they are above the network peer count.
But if the number of peers suddenly increases, new nodes can’t make connections, and therefore can’t bootstrap.
Solution
We could increase the fixed reserved peers reconnection delays, so they are greater than the idle connection limit (3 seconds), giving new peers an opportunity to connect to the bootstrap nodes. This was done in PR #3448, but we could increase those limits more. However, increasing those limits also slows down bootstrap when the network is doing fine (or when other issues cause disconnections).
Instead, we should use a capped exponential backoff, like temporary bans, but with lower limits. Or we could re-use the same exponential backoff system for reserved peers, rather than overriding it with fixed reconnection intervals.
The text was updated successfully, but these errors were encountered:
Problem
When the network gets larger, bootstrap nodes can exceed the default inbound connection limit, and drop new connections. Currently we resolve this issue by increasing the connection limits on the command line, so they are above the network peer count.
But if the number of peers suddenly increases, new nodes can’t make connections, and therefore can’t bootstrap.
Solution
We could increase the fixed reserved peers reconnection delays, so they are greater than the idle connection limit (3 seconds), giving new peers an opportunity to connect to the bootstrap nodes. This was done in PR #3448, but we could increase those limits more. However, increasing those limits also slows down bootstrap when the network is doing fine (or when other issues cause disconnections).
Instead, we should use a capped exponential backoff, like temporary bans, but with lower limits. Or we could re-use the same exponential backoff system for reserved peers, rather than overriding it with fixed reconnection intervals.
The text was updated successfully, but these errors were encountered: