Support dynamic management of peers

Start by tracing the existing dynamic configuration loading for active and passive nodes, then follow how peers are looked up and disconnected. Implement the node.removePeers startup and reload behavior described in the issue, including the USER_REASON disconnect. Done means updated addresses are cached and matching peers are disconnected during reload without affecting other cases.

Background

Java-tron currently does not support node operators to flexibly manage the peer list of a node. For example, when a node operator wants to disconnect a peer (this peer may have a large network delay, or is inactive, etc.), there is no better way than restarting the node. Obviously, restarting the node is not a wise choice, because it will have a relatively large impact on other services that rely on the normal operation of the node. Moreover, after restarting the node, the node that you want to disconnect may still be able to quickly connect to the local node. Therefore, it is necessary for java-tron to implement the function of dynamically managing the peer list of nodes to provide node operators with more options for better node management.

Rationale

By looking at the implementation of Ethereum, it is found that Ethereum implements the following interfaces:

• AddPeer: Add a node to the static node list (the Ethereum node will actively initiate a connection with the static node).
• RemovePeer: Delete the peer from the static list and disconnect the peer.
• AddTrustedPeer: Set the connected peer as a trusted connection. Its connection will not be pruned later, nor will it be judged as a bad peer by the peer scoring mechanism.
• RemoveTrustedPeer: Delete the trusted connection identifier of the connected peer.

Currently, java-tron already supports dynamic addition and deletion of active nodes and passive nodes by dynamically loading configuration files.

• Active nodes: Active connection services will prioritize establishing connections with active nodes, and are not subject to the maximum number of connections.
• Passive nodes: They will be added to the trusted node list, and are not subject to the maximum number of connections when passively connected.

Therefore, we can dynamically delete peers by dynamically loading configuration files.

Implementation

1. Add a new configuration item node.removePeers in the configuration file:
   node.removePeers = [ "ip1:port", "ip2:port" ]

2. node.removePeers configures dynamic update logic:

• When the node starts, node.removePeers is loaded normally.

• When the configuration file is loaded dynamically, the latest node.removePeers is loaded and the network address list in the configuration is traversed:
  a. Check whether the network address exists in the last cache removePeers. If it does, get the peer according to the network address. If it is successfully obtained, send a disconnect message to the peer with the reason code USER_REASON and disconnect.
  b. No processing is done in other cases.

• Update the latest removePeers list to the cache.

Do you have ideas regarding the implementation of this feature?
yes
Are you willing to implement this feature?
yes