Node fails to synchronize blocks after a peer is randomly disconnected

[jakamobiii]

Software Versions

OS : Linux
JVM : Oracle Corporation 1.8.0_161 amd64
Version : 4.8.0

Expected behaviour

When the node has established multiple valid peer connections, it should be able to fetch block data from multiple available peers.
Even if a single peer is disconnected (including random disconnection), the node should automatically switch to other already connected peers to continue block synchronization, ensuring continuity and stability of the sync process.

Actual behaviour

During runtime, the following abnormal behavior was observed:

• The node successfully establishes approximately 30 P2P connections.
• However, during block synchronization, it appears that the node continuously requests blocks from only a single peer, while the other connections are not effectively utilized.
• When this peer is disconnected by the random elimination strategy, the following log is printed:

19:22:47.166 INFO  [peerWorker-5] [net](PeerConnection.java:184) Send peer /IP:50816 message type: P2P_DISCONNECT
reason: RANDOM_ELIMINATION

After this connection is terminated, the node does not automatically resume block requests from other already connected peers. The block height stops updating, and the node enters a state where it can no longer continue block synchronization.

Based on logs and observed behavior:

• There appears to be a strong single-peer dependency for block data syncing.
• When the random elimination strategy is triggered, the only actively used peer is disconnected, which raises the question of whether there is an issue with the random elimination strategy.

Frequency

This issue is not consistently reproducible and was not clearly observed in earlier runs.

[zeusoo001]

The current random disconnection strategy is relatively simple, the logic for “random disconnection” is as follows:

1. If the number of established peers is less than the configured maximum connections, return immediately.
2. Filter out trusted nodes.
3. If the number of peers in the broadcasting state ≥ 3, select one of the broadcasting peers using a “weighted random algorithm” and disconnect it.
4. Otherwise, randomly eliminate one peer from the syncing peers:
   1. If needSyncFromPeerCount < 2, eliminate one peer from the needSyncFromUs nodes.
   2. Otherwise, randomly eliminate one peer from all syncing peers.

Under this strategy, any node except trusted nodes has the potential to be disconnected. This is a good issue, and we can discuss how to optimize this strategy to minimize the disconnection of good connections.