Repository navigation
Support dynamic management of peers #6296
Description
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
-
Add a new configuration item node.removePeers in the configuration file:
node.removePeers = [ "ip1:port", "ip2:port" ] -
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
Activity
fyyhtx commentedon Apr 22, 2025
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 commentedon Apr 22, 2025
@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 commentedon Apr 23, 2025
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 commentedon Apr 23, 2025
@jakamobiii I guess you may not have enabled the dynamic configuration file loading function. You can set the configuration item
node.dynamicConfig.enableto true and restart the node to try.fyyhtx commentedon Apr 24, 2025
@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?
SeriousCoding789 commentedon Apr 24, 2025
@jwrct For Ethereum the
RemovePeeraction, will it be put into the blacklist and never be connected?jwrct commentedon Apr 24, 2025
@Sunny6889 For the RemovePeer action of Ethereum, it will not be put into the blacklist and the connection can be established again later.
SeriousCoding789 commentedon Apr 24, 2025
@jwrct So does it means Ethereum also does not have a blacklist feature?
jwrct commentedon Apr 24, 2025
@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 commentedon Apr 24, 2025
@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 commentedon Apr 25, 2025
@jwrct Is there already a specific implementation plan? If so, could you share it with everyone for discussion to better optimize the plan?
jwrct commentedon Apr 25, 2025
@fyyhtx Yes, you're right. I already have an initial plan here:
node.removePeersin the configuration file:node.removePeers = [ "ip1:port", "ip2:port" ]When the node starts,
node.removePeersis 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 commentedon Apr 28, 2025
@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 commentedon Apr 28, 2025
@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.
13 remaining items
317787106 commentedon Sep 30, 2025
The access authentication architecture has been fully designed, and upon completion, it will allow for the continued support of dynamic peer management.
317787106 commentedon Dec 24, 2025
@jwrct This feature can be implemented in the framework of #6497.
waynercheung commentedon May 15, 2026
@317787106 @jwrct Since this has been discussed in #6497 , would it make sense to close this one and continue the conversation there?
halibobo1205 commentedon May 15, 2026
closed by #6497.
SeriousCoding789 commentedon Sep 22, 2026
Closing this in favour of #6989.
Context for anyone arriving from a link: #6989 is the concrete implementation issue that finally lands the capability, so this is the right moment to close the original.
What #6989 covers, on top of the Admin JSON-RPC framework from #6497:
admin_addPeer/admin_removePeeradmin_disconnectPeeradmin_listActivePeersadmin_blockIp/admin_unblockIp/admin_listBlockedIpsThis is a superset of what was proposed here. The original design routed removal through a
node.removePeersconfig entry applied on dynamic config reload; #6989 exposes it as an Admin request instead, which gives immediate structured feedback and avoids coupling an operational action to a config-file edit. It also adds the two things this issue did not cover: inspection of current peerstate, and a persistent IP blocklist that survives a restart — the original concern that "the peer you disconnected can just reconnect right away" is only actually solved by that second one.
@jwrct — thanks for the original write-up and the Ethereum comparison; the AddPeer / RemovePeer / trusted-peer semantics you documented carried directly into the method set above. Please follow along and comment on #6989 if anything from the original design is missing there.