Support dynamic management of peers

[jwrct]

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

[fyyhtx]

This feature looks very good, but I still have a question, if the connection of the specified peer is disconnected, will the reconnection request be accepted?

[jwrct]

@fyyhtx Yes, a peer that is designated to be disconnected can be re-accepted, but only after it has passed the banding period. One thing to be clear is that we are not implementing a blacklist feature.

[jakamobiii]

I tried to add active nodes and passive nodes without restarting the nodes, but it didn't seem to work. Is there a problem with the dynamic loading of configuration files function? Or does the dynamic loading of configuration files function need to be enabled?

[jwrct]

@jakamobiii I guess you may not have enabled the dynamic configuration file loading function. You can set the configuration item node.dynamicConfig.enable to true and restart the node to try.

[fyyhtx]

@jwrct Do you want to specify the peer you want to delete through configuration? As you said, the disconnected peer can still be accepted later. When you want to delete a peer again, but it already exists in the configuration, how to deal with this situation?

[Sunny6889]

@jwrct For Ethereum the RemovePeer action, will it be put into the blacklist and never be connected?

[jwrct]

@Sunny6889 For the RemovePeer action of Ethereum, it will not be put into the blacklist and the connection can be established again later.

[Sunny6889]

@Sunny6889 For the RemovePeer action of Ethereum, it will not be put into the blacklist and the connection can be established again later.

@jwrct So does it means Ethereum also does not have a blacklist feature?

[jwrct]

@Sunny6889 Yes, I think so. I have checked the Ethereum code implementation and found nothing about it. If you have any new findings, please provide some clues, I will be very grateful.

[jwrct]

@jwrct Do you want to specify the peer you want to delete through configuration? As you said, the disconnected peer can still be accepted later. When you want to delete a peer again, but it already exists in the configuration, how to deal with this situation?

@fyyhtx Yes, by default, a new configuration file is loaded every 10 minutes. You can delete the peer information from the configuration after confirming that the peer has been deleted, or remove the existing configuration before deleting the peer, and wait 10 minutes before deleting the peer.

[fyyhtx]

@jwrct Is there already a specific implementation plan? If so, could you share it with everyone for discussion to better optimize the plan?

[jwrct]

@fyyhtx Yes, you're right. I already have an initial plan here:

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.

[fyyhtx]

@jwrct You proposed to pass in the network address of the peer you want to delete by dynamically loading the configuration. I have to admit that this method is the simplest one to implement at present. However, I would like to say that this method has a disadvantage, that is, you need to log in to the server where the node is located every time, which may not be the most convenient way for some node operators.

[jwrct]

@fyyhtx Your concerns are reasonable. Ethereum implements the peer you want to delete through an API with permission control. This method is indeed much more convenient for node operators. However, java-tron currently does not implement permission control for the API. We can consider implementing this first, and then specify the peer to be deleted in this way.

[fyyhtx]

@jwrct I think it is better to implement API permission control first, and then specify the peer to be deleted through the API. I hope it will be implemented soon.

[jwrct]

@fyyhtx I am very happy to receive your suggestions. If there is any progress, I will announce it here in time and adjust the implementation plan in the text in time. Thank you again!

[jwrct]

I have initially implemented a version of the code to specify the peer to be removed through the API, but the newly added API has not yet been given permission control, which will be added later. For the specific code, please refer to: jwrct@9919bd6

[317787106]

@jwrct A JWT-like authentication scheme is currently being designed, and we can collaborate on it later.

[jwrct]

@317787106 I am very excited to see your reply and look forward to collaborating with you.

[GordonLtron]

If there is no update i suggest to close the issue

[jwrct]

Milestone Update (2025-05-27)

• Current Status: In Development （80% completed, the dynamic peer deletion function has passed the unit test）
• Next Steps:
  • Depends on the implementation of API permission control function
• Responsible Persons: @jwrct