Skip to content
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

feat(net): disconnect from inactive nodes if necessary #5924

Merged
merged 8 commits into from
Jul 29, 2024

Conversation

317787106
Copy link
Contributor

What does this PR do?
To maintain the stability of the network and prevent node isolation, the node needs to be disconnected from inactive nodes on a regular basis. Three strategies are adopted:

  1. If the node is in a LAN and the number of peers is greater than or equal to minConnection, disconnect from the earliest inactive peer that has been inactive for more than the threshold time.
  2. If the node is isolated, disconnect from one active peer if the active number is greater than or equal to minActiveConnection. At the same time, disconnect from some passive peers but ensure that the retention percentage of peers is greater than or equal to 80%.
  3. Optimize the random disconnect policy and only disconnect from the peer that has remained inactive for too long.
    Why are these changes required?

This PR has been tested by:

  • Unit Tests
  • Manual Testing

Follow up

Extra details

private static final int initialDelay = 300;
private static final String esName = "resilience-service";
private final ScheduledExecutorService executor = ExecutorServiceManager
.newSingleThreadScheduledExecutor(esName);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that you have added 3 tasks to be scheduled and executed in the same executor, the scheduling between different tasks will be affected, right? Have you considered splitting the tasks into different executors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any task only consume several milliseconds at most. There is no need to split them in different executors.

List<PeerConnection> peers = tronNetDelegate.getActivePeer().stream()
.filter(peer -> !peer.isDisconnect())
.filter(peer -> now - peer.getLastActiveTime() >= inactiveThreshold)
.filter(peer -> !peer.getChannel().isTrustPeer())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change the original logic, not excluding active connections.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Original logic don't have the inactiveThreshold restrict, it has many conditates. The number of peers whose inactive time is more inactiveThreshold is very small, it has very little condidates, so there is no need to exclude active connections.

@lvs007 lvs007 merged commit 54b0395 into tronprotocol:release_v4.7.6 Jul 29, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants