Grandpa consensus affects p2p links

[gguoss]

When the finalized of the nodes are inconsistent, the nodes that are finalized are more easily connected.

There are 3 validators in **3992**height, however, only 1 validator in **3990** height. So in **3990** height's validator can't connect other node.

[rphmeier]

cc @arkpar , it may have something to do with block announcements?

Also, it might be a case that the poor connectivity causes the validator to be behind, not the other way around.

[gguoss]

• problem 1: listen_addrs: ["/ip4/127.0.0.1/tcp/30333", "/ip4/192.168.1.236/tcp/30333", "/ip4/115.193.183.144/tcp/30333", "/ip4/0.0.0.0/tcp/30333"].
  0.0.0.0 can't listen?

• problem 2: INFO sync Dropping 1 because "Sent unknown consensus engine id" ,Dropping PeerId(QmSX5KnWLHo5nd3iK6Q99tQEF2v9StAoHQGEb3XY7g3QHk) on purpose (Polkadot CLI and logging initialization. #1, Dialer { address: "/ip4/127.0.0.1/tcp/30333" }, None).
  this peer is god node, can't dropping because unknown consensus engine id？

• problem 3: INFO substrate Idle (0 peers).
  0 peers can't run gossip？

[gguoss]

can't connect 0.0.0.0:port, can reconnect 127.0.0.1:port

[gguoss]

Validator (auth1, auth2, auth3, auth4)
problem1: In height 17400(Grandpa update authority, deposit log), affect p2p links.

problem2: auth 1~4, p2p connected correct, but height not consistent, (auth3 ,auth4) in 17700 ad spawn block. (auth1 and auth2 ) in 17433 and spawn block.

[gguoss]

auth1.log
17400 is finalized by grandpa. but auth1 continue rollback (< 17400).

[rphmeier]

Related to #1944 perhaps

[rphmeier]

@gguoss how does latest master do?

[gguoss]

Before #1944 test.
Now used latest master test , p2p looks good.

[gguoss]

4 validators (A,B,C,D )
A,B,C same finalized height(same round). then start D(D's round < (A or B or C)'s round).

In Mac OS, D can't connect any node,
libp2p-2 INFO sync Dropping 1 because "Sent unknown consensus engine id".
if D not authority, only full node , can sync.

In Ubuntu OS, A, B, C, D 4 validators run ok.

[rphmeier]

@gguoss I'll keep this one open for now -- we are in the middle of some network overhaul to make this better.

[arkpar]

This is now resolved as far as I know