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. 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
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).
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
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.
@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)
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.
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é.
