Connectivité WS2P

La plupart du temps ça fonctionne oui, mais j’ai eu le contre-exemple hier avec mon Raspberry PI qui avait aussi plusieurs milliers de blocs de retard. Il a fini par décrocher.

La raison ? Il a perdu la dernière connexion WS2P qui lui restait, et le crawling BMA était désactivé.

Comment corriger cela ? Honnêtement je ne sais pas. :confused: Car que peut-on faire face à l’absence de réseau pour un nœud miroir ? Peut-être qu’un tel nœud devrait être configuré avec le crawling BMA, connaissant d’avance sa faiblesse de connexion inter-nœuds. Ou bien laisser BMA désactivé, mais alors il est nécessaire d’avoir un nœud préféré qui a aussi enregistré le miroir comme privilégié.

Bref, on pourrait recadrer cette exigence par un “sous réserve de configuration réseau adaptée”.

Développer la culture de l’invitation : désormais les nœuds miroirs invités sont prioritaires par rapports au nœuds membres :slight_smile:

En effet actuellement WS2P est ainsi fait qu’un noeud miroir qui n’est invité nul part aura le plus grand mal a rester synchronisé au réseau, cela est volontaire et assumé de ma part pour sécuriser davantage le réseau, un noeud non-membre doit désormais être invité par d’autres nœuds (pas forcément membres d’ailleurs, ça peut être des nœuds miroirs qui sont eux mêmes invités par d’autres noeuds, certe il faut des nœuds membres au bout de la chaine d’invitations).

Ça ne me paraît pas du tout déconnant :slight_smile:

1 « J'aime »

Ton noeud n’avait pas de possibilité de recevoir des connexions en INCOMING ? Parce qu’il me semble qu’il serait intéressant que les nœuds non membres et non invités soient a minima des hub de connexion pour les nœuds qui n’ont pas de possibilité d’avoir de connexions INCOMING :slight_smile:

Il aurait pu, mais il n’en avait pas. Il y a peut-être un coup à jouer à ce niveau là. Genre une règle :

Dès que le nœud se connecte à un nouveau pair, il lui transmet sa fiche.

On n’a pas de telle règle aujourd’hui, c’est sûrement un tort car du coup le réseau est au courant avec retard de la possibilité de connexion.

1 « J'aime »

Ça ressemble a une feature que je prévois pour la 1.7 :

Créer un message de type NEWCOMER PEER pour qu’un nouveau noeud vierge se fasse connaitre immédiatement

Voir ici : https://git.duniter.org/nodes/typescript/duniter/issues/1203

C’est bien la même idée :slight_smile: À mon avis on n’a pas besoin d’un nouveau type de message, juste à transmettre notre fiche sur connexion.

Mais tu avais peut-être une idée plus vaste avec ce NEWCOMER PEER ?

Oui le but est de soulever la difficulté qu’a un nouveau noeud jamais apparu avant sur le réseau (ou quia changer de endpoint) de se faire connaitre. Il faut qu’il arrive a établir une 1ère connexion ws2p pour se faire connaitre du réseau, ce qui peut prendre du temps, typiquement si la première vague d’essai échoue il doit attendre 10 min sans aucune connexion avant de retenter une vague d’essai.

Mon idée était de créer un nouveau type de message qui soit destiné a être temporaire, donc même pas besoin de websoket dans l’aboslu, mais sa peut-etre un websocket fermer immédiatement après l’envoi du signal. L’idée consiste, au démarrage du noeud uniquement, a envoyer un signal a tout les nœuds dont il a connaissance du endpoint juste pour leur dire “hey, j’existe et je suis joignable a tel endpoint”.
Ainsi il sera susceptible de recevoir des connexions INCOMING même s’il n’a jamais réussi a établir de connexion OUTCOMING.

1 « J'aime »

@cgeek on pourrait fusionner ton idée et la mienne de la façon suivante :

Modifier le protocole d’établissement d’une connexion : lors d’une tentative de connexion, le noeud demandeur de la connexion envoi sa fiche de peer au noeud récepteur, et le noeud récepteur accepte et enregistre la fiche de peer puis décide seulement après d’accepter ou de refuser la connexion selon les règles actuelles (quotas, priorités, etc)

1 « J'aime »

Oui parfait : lors du message CONNECT, pouvoir adjoindre la fiche de pair.

C’est important que ce soit pile à ce moment, car ça permet de laisse libre le pair contacté de répondre ou non à la connexion, donc de se réserver le droit de générer un timeout pour contrer les attaques.

Si c’est cela, ça me conviendrait parfaitement :+1:

Mais ça demande de passer en WS2P V2.

2 « J'aime »

Merci ça précise mon idée, je note de suite cela dans le ticket #1203 :slight_smile:

C’est déjà prévu :wink:

1 « J'aime »