Peer Status Information Abnormal

[liuyifei001]

Software Versions

OS: Linux
JVM: Red Hat, Inc. 1.8.0_352 amd64
Git: a8ad2a169e58946b5b8de6ecf7b7ef5b8db05aff
Version: 4.7.5
Code: 18306

Expected behaviour

I understand that this field is the common block height of two nodes. But why is the item last_know_block_num of some peer status information always 0? Is this normal?

Actual behaviour

We can see from the log in every 10 seconds, like this:

Most peers’s last_know_block_num is 0. For instance, my node has 30 peers, but 21 of them are 0.

Frequency

Every 10 seconds.

Steps to reproduce the behaviour

Run the fullnode with the main_net_config.conf, and Nile testnet has the same problems.

Backtrace

============ Peer stats: all 30, active 5, passive 25

Peer /52.53.168.1:41388
connect time: 389s [40ms]
last know block num: 0
needSyncFromPeer:false
needSyncFromUs:false
syncToFetchSize:0
syncToFetchSizePeekNum:-1
syncBlockRequestedSize:0
remainNum:0
syncChainRequested:0
blockInProcess:0

Peer /52.47.132.214:32804
connect time: 209s [42ms]
last know block num: 0
needSyncFromPeer:false
needSyncFromUs:false
syncToFetchSize:0
syncToFetchSizePeekNum:-1
syncBlockRequestedSize:0
remainNum:0
syncChainRequested:0
blockInProcess:0

Peer /3.75.249.184:41690
connect time: 388s [46ms]
last know block num: 0
needSyncFromPeer:false
needSyncFromUs:false
syncToFetchSize:0
syncToFetchSizePeekNum:-1
syncBlockRequestedSize:0
remainNum:0
syncChainRequested:0
blockInProcess:0

Peer /185.8.107.40:18888
connect time: 120079s [47ms]
last know block num: 62737275
needSyncFromPeer:false
needSyncFromUs:false
syncToFetchSize:0
syncToFetchSizePeekNum:-1
syncBlockRequestedSize:0
remainNum:0
syncChainRequested:0
blockInProcess:0

Peer /65.21.48.128:51400
connect time: 149s [52ms]
last know block num: 0
needSyncFromPeer:false
needSyncFromUs:false
syncToFetchSize:0
syncToFetchSizePeekNum:-1
syncBlockRequestedSize:0
remainNum:0
syncChainRequested:0
blockInProcess:0

When submitting logs: please submit them as text and not screenshots.

[fyyhtx]

@liuyifei001 If this value remains 0 all the time, it is definitely abnormal. The issue should be that after processing the broadcast block, the value last_known_block_num was not updated properly.

[317787106]

@liuyifei001 That's abnormal and it's a problem that we ignored ago.
@fyyhtx You seems to be right. After handling the block when broadcasting, we should set the block_both_have for peers.

[317787106]

@liuyifei001 I have resolve this problem like this: After processing a block from one broadcasting peer, node will look up the blockID in all peers' advInvReceive to decide if the peer has sent me the block inventory already. If sent, the block_both_have will be set. See more details on #5925

[lvs007]

Done: merge to release_v4.7.6