Oui, cela dépend du nœud consulté, puisque les piscines (où sont stockées les certifications) ne sont forcément synchrone (car hors blockchain).
C’est une problématique que j’ai déjà remonté, je crois. L’idée que j’avais de mon côté était que des noeuds puisse forcer des synchronisations de piscine, en interrogeant leurs voisins. Peut-etre @Elois pourrait nous faire ca dans un noeud spécialisé ?
Bien vu @inso ! Voila qui me confirmes que je dois faire cela aussi… mais peut-être dans un noeud ES Cesium+ finalement.
Pour ce qui ai de la synchronisation des piscines des nœuds, il me semble que ce serait plutôt un role pour le module duniter-crawler non ?
Si j’ai bien compris, pour le moment les nœuds se contentent d’envoyer les documents à leurs pair, sans se soucier de savoir si leurs pairs ont intégrés ces documents dans leurs piscines respectives. Peut-être que cela suffit coté nœuds, je crains que si, les nœuds commencent à se préoccuper des piscines de leurs pairs, cela sature inutilement le réseau inter-nœuds.
je comprend l’intérêt d’avoir une vue globale des piscines des nœuds coté client, mais du coup je pense que c’est aux clients de balayer le réseau comme le fait déjà Sakia, et pas à Duniter et ses modules.
Je crois également que ce qui nous apparaît comme asynchrone avec quelques nœuds, nous ne le percevrons même plus avec plusieurs dizaines de nœuds car cela démultiplie les chemin possibles ente 2 nœuds et donc les synchronisations ce feront beaucoup mieux naturellement
les nouvaeux noeuds, qui par définition ont des piscine vides
les noeuds arrêtés (par exemple ceux des utilsiateurs lambda qui éteignent leur machines la nuit)
Justement, il ne faut pas que ces soient “les noeuds”, mais un noeud spécialisé, qui rend se service de “prise en charge des nouveaux noeuds”. Une sorte de mise à jour quoi
Comme le réseau peut tourner sans, c’est juste un service additionnel. Un peu comme Remuniter : pas besoin de 1000 noeuds à faire cela.
Ce n’est que mon avis (provisoire !)
pas sûr : comme je le disais les noeuds peuvent s’éteindre et repartir, etc. Et les inscriptions en attente peuvent alors être percus comme “dossier incomplet” (il manque par exemple une certification) alors que si on réunissait toutes les piscines, il y aurait bien le nombre de certification requis.
Si l’on ne prend pas garde à ce genre de foncionnalités, on va voir apparaitre “des noeuds de référence”, que les personnes lambda préfère utiliser prioritairement, car elles savent que plus de monde pointe dessus, et que leur dossier seront complet plus tôt. C’est ce que nous avons constaté pour les tests du Sou : avec 5 certifications requises, le temps est importante, alors tu fais vite gaffe à ne pas perdre une certification dans un piscine quelque part…
Pour réduire le problème, il faudrait pour commencer que Cesium broadcast les documents aux noeuds membres qu’il connait. On réduirait d’un coup drastiquement la dispersions des piscines de noeuds.
Ca n’a pas sens pour moi. Le rôle d’un client n’est pas de faire de la synchro de réseau.
Je suis d’accord pour diffuser le document sur chaque fork, mais pas sur tous les noeuds. C’est pas du tout opérationnel comme truc.
…imagines 1000 noeuds.
Le client étant client d’un réseau P2P il devrait s’adapter aux contraintes P2P. Et notamment, faire du broadcast pour faire apparaitre le document en multiples endroits sur le réseau, qui n’est ni uniforme ni cohérent. (La blockchain est cohérente, le réseau qui la construit non).
Rien que le broadcaster aléatoirement à N noeuds au lieu d’un améliorerait drastiquement la situation. Tu commences à N noeuds, qui le broadcastent à N autres noeuds. En deux round le doc est diffusé à N² au lieu de N. Il y a donc N² noeuds qui peuvent potentiellement se retrouver avec tout les documents à inscrire en blockchain.
Un cas concret : si le noeud utilisé par Cesium voit sa piscine pleine, il va rejeter les docs. Les utilisateurs ne peuvent plus diffuser leurs documents. Si Cesium broadcastait les docs, il n’y a pas ce problème.
Oui, pas besoin que Cesium diffuse à 400 nœuds : il en suffit de 2 ou 3 car la diffusion est ensuite exponentielle. Mais bien sûr si tu le fais que sur 1 seul nœud qui, pour une raison ou une autre, foire sa diffusion, le document n’est pas transmis.
Ensuite je partage l’avis d’elois : d’une part un plus grand volume de nœuds tend à créer une masse stable de nœuds, et crée donc une inertie dans le partage des documents. Celle-ci est hachée aujourd’hui à cause de la grande représentation des nœuds diurnes par rapport aux nœuds permanents.
D’autre part duniter-crawler est un module de duniter qui est tout à fait apte à, mettons toutes les 20 minutes, avoir un regard rapide sur les documents en piscine de quelques autres nœuds et se les approprier. De fait, les nouveaux documents sont alors automatiquement rebroadcastés.
Je suis en train de le coder là, c’est pas vraiment ni long ni difficile à réaliser.
Ce qui serait intéressant de la part du crawler serait de chercher des documents qui leurs permettent de compléter des inscriptions et de les sauvegarder localement. Ils ont une identité en attente, elle a 2 certifs, il manque l’adhésion et 1 certif… le crawler chercherait en priorité ces 2 documents là, afin de pouvoir inscrire des données utiles dans le block suivant.
Le crawling bête et méchant, je trouverais ça dangereux de l’activer en continu pour tout les noeuds. D’après moi :
Le broadcast est censé diffuser le document pour les noeuds accessibles à un instant T (problématique du réseau non cohérent dans l’espace)
Le crawling permet aux noeuds qui étaient éteints de récupérer des docs en piscines diffusés pendant qu’ils étaient inaccessible (problématique du réseau non uniforme dans le temps)
Du coup, je pense que :
le crawler “brut” devrait se lancer lors du démarrage du noeud, mais qu’ensuite il devrait simplement attendre de recevoir des documents broadcastés.
Le crawler “smart” aurait pour but d’aider le calculateur de bloc à pouvoir insérer des documents dans la blockchain.
Pourquoi cela ? Par exemple aujourd’hui le crawler est activé toutes les 20 secondes au démarrage, et tend vers 4 minutes après plusieurs heures d’activité.
Il y a probablement une échelle ou le réseau risque de saturer du crawling actif. (D’ailleurs, c’est en partie pour ça que tu m’avais demandé de faire passer Sakia sur le mode websockets, il me semble).
Reprenons le problème qui impliquerait apparemment de crawler un maximum de piscines et de tout rediffuser :
Pour écrire les documents d’adhésion initiaux, il faut un groupe de N documents. Tant que les N ne sont pas rassemblés, ils ne peuvent pas être écrits.
Un nœud cherche à construire des blocs qui contiennent des données. Il produit des blocs sans adhésion tant qu’il n’a pas un ensemble complet de documents d’adhésion.
Parcourir toutes les piscines pour avoir la représentation la plus complète possible va impliquer :
Des recherches couteuses lors de la sélections des documents à écrire dans le bloc suivant
Une saturation des piscines de tout les nœuds, au point ou les clients ne pourraient plus diffuser de document
On voit, je pense, que cette logique coute cher en ressources alors que c’est un des rôles de la blockchain que d’avoir une représentation totale des données, pour un coût réseau plus faible.
De mon point de vue :
Le crawling brut devrait servir à l’initialisation de la piscine avec des documents ou des ensembles de documents partiels
Le broadcast devrait servir à recevoir des documents ou des ensembles de documents partiels, pour les nœuds qui sont allumés à un instant T
Le crawling intelligent devrait servir à compléter la piscine pour que l’ensemble de document partiel devienne complet et puisse forger un bloc
D’autant plus que la rotation du minage fait que si 3 adhésions (identité+certs+ms) sont réparties sur 3 nœuds, elles ont tout autant de chances d’êtres inscrites que si elles étaient présentes sur les 3 nœuds (grossièrement).
C’était juste pour lire cela que je t’ai posé la question, car je me doutais que tu supposais un crawling “complet” du réseau.
Or, c’est un crawling bien moins actif que je réalise déjà avec le pulling de blocs, ou encore celui pour connaître les pairs injoignables qui le sont de nouveau : je prends un pool de 4 nœuds, aléatoirement et toutes les X périodes, et je ne fais que ceux-là.
Il pourrait être intéressant d’analyser le % de document découvert par crawling actif (après initialisation) vs les % de document découverts par broadcast du coup Intuitivement, je ne vois pas très bien ce qu’il pourrait apporter (sauf pour les noeuds inaccessibles depuis l’extérieur qui sont un autre problème je pense)
En partant du nœud gtest.duniter.org, puis en crawlant successivement les autres nœuds du réseau, je constate que :
La vaste majorité des documents se trouve stockée sur gtest.duniter.org, dont des dossiers complets qui ne passent pas en blockchain.
Il existe 4 certificats “perdus” sur mon nœud (cgeek.fr:10900) :
New cert 8Fi1VSTbjkXguwThF4v2ZxC5whK7pwG2vcGTkPUPjPGU -> urodelus
New cert 8Fi1VSTbjkXguwThF4v2ZxC5whK7pwG2vcGTkPUPjPGU -> nay4
New cert 8Fi1VSTbjkXguwThF4v2ZxC5whK7pwG2vcGTkPUPjPGU -> filb
New cert D3nN6CsWFPmqcWdjNJbE1PcHXyjWaBQPpAFn1ZyXRAAU -> DebOrah
2nd résultats
En partant du nœud cgeek.fr:10900, donc un nœud membre, puis en crawlant successivement les autres nœuds du réseau, je constate que :
Les nœud possède toutes les identités, ainsi que leurs adhésions, MAIS il lui manque de nombreuses certifications :
New cert CFP3oacjwDJARL89D2Gkz6LeMoVAu4ggE65CvqSp9Q9K -> matiou
New cert 7tuTjCfZ7MTyVHj7GrfA8zNJ1mpWkKL9KxkoaQNpjyAe -> matiou
New cert 7iBkcyryuikxLotKgLABb4ViWCcfZowUseG4z48ochax -> matiou
New cert 5ocqzyDMMWf1V8bsoNhWb1iNwax1e9M7VTUN6navs8of -> matiou
New cert 7KL2QXXFULDpsQY4UdSr5oEVx6rFE6oxeagRdkCX35bf -> matiou
New cert CSjgcGguFJe3ghBBjjGyNVdvC3rqtXE7rSxUaLzjxBhR -> gerard94
New cert 7iBkcyryuikxLotKgLABb4ViWCcfZowUseG4z48ochax -> gerard94
New cert 2mtUitLDcvw9bjLQaw5PuFjaHb6V4USAx9BDkx3vLcu3 -> gerard94
New cert CFP3oacjwDJARL89D2Gkz6LeMoVAu4ggE65CvqSp9Q9K -> urodelus
New cert 7iBkcyryuikxLotKgLABb4ViWCcfZowUseG4z48ochax -> urodelus
New cert 7KL2QXXFULDpsQY4UdSr5oEVx6rFE6oxeagRdkCX35bf -> urodelus
New cert 2mtUitLDcvw9bjLQaw5PuFjaHb6V4USAx9BDkx3vLcu3 -> SybilleSG
New cert 5ocqzyDMMWf1V8bsoNhWb1iNwax1e9M7VTUN6navs8of -> Sivmatt
New cert 7KL2QXXFULDpsQY4UdSr5oEVx6rFE6oxeagRdkCX35bf -> Thatoo
New cert CSjgcGguFJe3ghBBjjGyNVdvC3rqtXE7rSxUaLzjxBhR -> Caizohan
New cert D3nN6CsWFPmqcWdjNJbE1PcHXyjWaBQPpAFn1ZyXRAAU -> Caizohan
New cert 2mtUitLDcvw9bjLQaw5PuFjaHb6V4USAx9BDkx3vLcu3 -> Caizohan
New cert XeBpJwRLkF5J4mnwyEDriEcNB13iFpe1MAKR4mH3fzN -> nay4
New cert CSjgcGguFJe3ghBBjjGyNVdvC3rqtXE7rSxUaLzjxBhR -> nay4
New cert 7tuTjCfZ7MTyVHj7GrfA8zNJ1mpWkKL9KxkoaQNpjyAe -> filb
New cert 7iBkcyryuikxLotKgLABb4ViWCcfZowUseG4z48ochax -> Darunya
New cert 8xgcva5AKNdqmRCR6qimEhivoqEFraz7FkrMGHdrcDKb -> RavanH
New cert 5ocqzyDMMWf1V8bsoNhWb1iNwax1e9M7VTUN6navs8of -> RavanH
New cert 7KL2QXXFULDpsQY4UdSr5oEVx6rFE6oxeagRdkCX35bf -> RavanH
New cert 2mtUitLDcvw9bjLQaw5PuFjaHb6V4USAx9BDkx3vLcu3 -> gege53
New cert 7iBkcyryuikxLotKgLABb4ViWCcfZowUseG4z48ochax -> DebOrah
New cert bDq9H48BVEAHydtH8MHjrmdRnuq8d8GMUaPSzEn8TkC -> DebOrah
New cert 2mtUitLDcvw9bjLQaw5PuFjaHb6V4USAx9BDkx3vLcu3 -> DebOrah
New cert 7iBkcyryuikxLotKgLABb4ViWCcfZowUseG4z48ochax -> bruno
New cert 5ocqzyDMMWf1V8bsoNhWb1iNwax1e9M7VTUN6navs8of -> MichelDuchemin
New cert HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk -> gpsqueeek
New cert bDq9H48BVEAHydtH8MHjrmdRnuq8d8GMUaPSzEn8TkC -> gpsqueeek
New cert 7iBkcyryuikxLotKgLABb4ViWCcfZowUseG4z48ochax -> gpsqueeek
New cert 8Fi1VSTbjkXguwThF4v2ZxC5whK7pwG2vcGTkPUPjPGU -> gpsqueeek
New cert 2mtUitLDcvw9bjLQaw5PuFjaHb6V4USAx9BDkx3vLcu3 -> Ben31
New cert HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk -> carotte46
New cert D3nN6CsWFPmqcWdjNJbE1PcHXyjWaBQPpAFn1ZyXRAAU -> carotte46
New cert CSjgcGguFJe3ghBBjjGyNVdvC3rqtXE7rSxUaLzjxBhR -> rimek
Conclusion
Il y a vraisemblablement un défaut de propagation des certifications. Ce qu’il est possible de vérifier dans un test unitaire. Je vais faire cela.
En attendant, maintenant que l’inspection est terminée, je propage tout ce qui manque sur le réseau
Si l’on compte les lignes marquées d’un ✔ CERT, on compte 38 certifications qui ne s’étaient pas propagées. Il y a des chances que des membres passent dans les minutes qui viennent !
En regardant les logs, on peut voir que quand un document Peer arrive, celui-ci est bien propagé. Mais pas quand c’est un document CERT.
C’est bien ça notre problème.
edit: Bug reproduit en tests automatisés.
edit 2: livraison de la 0.90.3 en cours.
edit 3:
Pour la petite histoire … il y a fort longtemps, les certifications furent propagées. Imaginez : cela date du protocole 0.20. Puis à ce moment, j’ai décidé de découpler les identités de leurs certifications en termes de propagation et de traitement par les nœuds.
Et bien sûr … j’ai loupé la case “propagation” des certifs. Cela ne s’est jamais vu, car on a longtemps utilisé cgeek.fr:9330 comme nœud référent dans Sakia/Cesium. Du coup, tout tombait dessus, et mon nœud s’occupait d’intégrer les nouveaux venus, ajouter les certifications.
Mais voilà, GTest a changé l’environnement, et le bug a été révélé !
Bonsoir, merci pour l’explication, ça expliquerait pourquoi j’avais un delta hier entre les certifications que j’avais effectuées depuis une instance Cesium connectée au noeud gtest de @cgeek, et celles effectuées depuis une instance Cesium que je teste sur mon serveur, et connectée à mon noeud. Je n’avais pas la même liste de certifications en attente. J’ai appris un truc grâce à vous sur cette histoire de piscines et de certifications qui ne sont pas dans la blockchain.
