Try to reconnect on a regular basis

When we start Duniter with WS2P private enabled, the node tries to connect to known peers.

But then later on if we loose all of our connections that were established on new Peer reception, we might end in a situation with no connection at all! If the connection is only made on new Peer event, then we cannot have any new connection. We get isolated.

Thus, a solution would be to retry initial connections on a regular basis, or when the number of connected nodes becomes too low.

It's a job for prefered-nodes list. We could even allow the user to manually enter public WS2P endpoints of their preferred nodes. But without it, we can : never remove the peer datas from your prefered nodes and use them in case of isolation.

Except the manually entered endpoints, when do we feed this list of prefered nodes?

We can define a default prefered list and informed the user via the web-ui that it is highly recommended to customize his preferred node list to avoid overloading default nodes. Default nodes should commit to keeping a public ws2p endpoint stable and unlimited in number of public connections. a may be the official mirror nodes of local groups: g1.le-sou.org g1.monnaielibreoccitanie.org Of course, with e the official node g1. duniter.org too.

Why don't we just randomly select nodes to connect to? I mean, we can of course define personalized nodes as well, but this wouldn't be selected by the developers.

Why don't we just randomly select nodes to connect to?

How to select a node if you don't have any more peer records in database ? Unless you randomly select preferred peers before, when the node is not yet isolated. Yes, it's also a possibility.:)

Oh OK! No I didn't mean that we do not have records in the database anymore. We do. We have all of them.

It's just that we don't see the updates, i.e. the flow of new Peer documents that either is a new peer or an existing one which updates its peer document on a regular basis, which we receive through WS2P. I've coded the connection algorithm to only retry a connection when such an update occurs. But of course, if zero peers are connected to you, absolutely no new peer or update can reach you! Which makes your node isolated.

That was the sense of the issue. So I proposed to retry to connect to peers that we know in the DB.

Okay I understand better, thank you:) In this case, we can indeed start on a random selection of nodes to be recontacted when the list of prefered is empty. But, if a list of prefered node is not empty, it seems to me relevant to recontact the nodes of this list as a priority

Yes that makes sense. Let's go for this then

I have a mirror node that is not recovering connections when it looses them.

The reconnection triggering is expected to occur on self peer document regeneration, but this node is WS2P Private only: I finally got a:

error: Peer with zero endpoints that is not already known

And the recovering mechanism isn't triggered. I never reconnect to peers.

The reconnection triggering is expected to occur on self peer document regeneration

No this is wrong, I looked into the code and the reconnection is triggered when a disconnection is detected:

https://github.com/duniter/duniter/blob/dev/app/modules/ws2p/lib/WS2PCluster.ts#L398-L410

But of course, if the mechanism gets triggered but you fail reconnecting at that moment (for example because you lost your internet connection), then you won't have another try later on when your connection is up.

So we need a systematic triggering, for example every 10 minutes with such code for ex.:

// Simulate a disconnection every 10 minutes
setInterval(() => this.server.push({ ws2p: 'disconnected' }), 1000 * 60 * 10)

mentioned in commit 414c5ece

mentioned in commit 1b068778