Managing fixed white black lists of peers from configuration

[ishantiw]

Description

In Phase 2 of lisk-p2p from LIP0004, we will have different peers list that user can set in the configuration when a node starts. This will include the following types of peer's lists:

• Blacklist Peer :

  • If a peer is blacklisted, then no incoming or outgoing connection is ever established to that peer
  • preference above all 8267dea 6577312

• Fixedlist Peer :

  • a permanent outgoing connection is established to that peer (if an incoming connection does not already exist) e210923
  • no subject to shuffle -> to be addressed by Add feature to disconnect peers as part of shuffling algorithm #3347
  • triggers reconnect if error (using exponential backoff functionality from SocketCluster) Not needed
  • manually removing from the configuration if connection failures after agreed period Not wanted
  • 4 at most 1edabab
  • users should be discouraged from declaring fixed peers 97527f4
  • exclusively connect to fixed peers + advertiseAddress=false + no shuffling (exchanges optional feature) -> to be addressed by Introduce advertiseAddress flag for peers #3661
  • preference over whitelisted attribute 6577312

• Whitelist Peer : a whitelisted peer is treated the same way as a normal peer with some exceptions

  • add to the triedPeers collection at the beginning a3dfb04
  • never removed from the triedPeers collection 1726f47
  • never banned by the banning mechanism 483074b
  • incoming connection from a whitelisted peer is never evicted and has precedence over any other (even over an existing one)
  • users should be warned in the configuration file to only declare trustworthy peers 97527f4

[diego-G]

We underestimated the complex of the issue. Next time we should create the checklist before estimating the points and decide how to tackle it. Ideally we should have fragmented it into several issues.