Have noticed some issues with discv5 in forming healthy relay mesh in status-desktop.
per @jm-clius .
The desktop/mobile app should also have almost equal number of peers as fleet nodes(or active nodes in the network) as
This is an indication that out of all the connected peers, gossipsub can form a healthy mesh.
[x] we can enable peerExchange client for relayMode so that more peers can be connected to.
[x] we also need to increase maxPeerConnections to 200/300 and change peerManager to try and connect to peers until we reach target. This doesn't mean all peers will be used as full Mesh peers, because gossipsub will still ensure atleast 4 fullMeshPeers are available and rest are only used as metadata peers(hence messages/data is not received from all connected peers). Since a user/node only sends few messages in comparison to what he/she receives connecting to more peers should not increase bandwidth usage significantly.
[x] for LightClient, maxPeerConnections can be left to 20
- [ ] lightclient - the peerConnector need not aggressively connect to all peers discovered. Rather this can be driven by store node connectivity and filter subscription manager.
Acceptance Criteria
Connectivity to peers should be high i.e each node should stabilize or reach atleast same peers as fleet nodes are connected to. It may take some-time for stabilization to happen
Light node connectivity should not change
There maybe issues in connecting to non-fleet peers as they are not reachable due to being behind a strict NAT or not able to reserve circuit-relay with fleet nodes.
Problem
Have noticed some issues with discv5 in forming healthy relay mesh in status-desktop.
per @jm-clius .
Observations are noted here https://github.com/waku-org/nwaku/issues/2810
Implementation
While this is debugged,
200/300
and change peerManager to try and connect to peers until we reach target. This doesn't mean all peers will be used as full Mesh peers, because gossipsub will still ensure atleast 4 fullMeshPeers are available and rest are only used as metadata peers(hence messages/data is not received from all connected peers). Since a user/node only sends few messages in comparison to what he/she receives connecting to more peers should not increase bandwidth usage significantly.- [ ] lightclient - the peerConnector need not aggressively connect to all peers discovered. Rather this can be driven by store node connectivity and filter subscription manager.Acceptance Criteria
Notes
Changes in go-waku to be made to increase number of peer connections supported and also allow peerManager to try connecting to peers. https://github.com/waku-org/go-waku/pull/1135 topicHealthReporting also has to be changed to indicate based on number of fullMeshPeers and overall peerCount. https://github.com/waku-org/go-waku/issues/1131
Future Steps
Once discv5 issue is resolved, then peerExchangeClient can be disabled in relayMode as peers would be discovered from discv5.