Il est intégré dans le paquet arch, de telle sorte que je peux faire systemctl start ipfs@hugo, c’est peut-être le cas également dans le paquet debian ?
Je ne sais pas précisément comment fonctionne la partie réseau p2p, mais il me semble qu’il y a un système de score et que des modifications peuvent mettre un peu de temps à être prises en compte, surtout si une ancienne “public address” déclarée était injoignable.
Il me semble que le plus important ici est d’avoir compris la couche de configuration et qu’elle fonctionne, on pourra s’attaquer plus tard à comprendre comment le réseau s’adapte à des modifications. Si cependant tu veux tester, tu peux changer de peer id en supprimant le fichier node.key, ce qui force duniter à en re-générer une au démarrage. Ça devrait changer quelque chose, mais c’est pas évident à tester.
Il n’y a eu aucun soucis non, à part ce que tu mentionne: temps de build, quantité de données nécessaires au build, … (heureusement que j’avais encore de la place sur la VM Oracle)
Juste un détail, j’ai du trouver par moi-même la bonne commande pour créer une image docker (pour l’architecture actuelle) pour ce repo; les documentations existantes pointent plus vers la création de packages, …
Mais en temps normal, il ne devrait pas être nécessaire de faire une image docker sois même si on arrive à corriger la création des images ARM automatiques
J’ai testé de changer le peer id pour le v2mirror; ça n’a pas d’incidence sur le nombre de peers.
J’ai également un v2validator qui toune depuis quelques jours et qui lui est toujours avec l’image docker officiele ARM (0.8.0) - pareil 11 peers (et il n’est mappé que via ProxyHost NGinx en https)
Du coup, je me demande si les différences pourraient être dues au fait que les autres noeuds duniter aient une référence vers notre noeud dans les bootnodes ou pas ?
Si oui, on pourrait le tester; mais il faut faire attention à ne pas perdre son “peer id” du coup si je comprend bien ?
Je ne pense pas que les bootnodes changent grand chose à la connectivité ensuite. Mais tu peux tester avec l’option --bootnodes en ligne de commande :
$ duniter --help
[...]
--bootnodes <ADDR>...
Specify a list of bootnodes
Oui, si un bootnode perd sa clé et change de peerId, il faut mettre à jour les bootnodes si on veut pas l’erreur 💔 The bootnode you want to connect to [...] provided a different peer ID than the one you expect .
Peut-être bien, je n’ai pas lu toutes les releases notes des versions de substrate. Et jusque là on n’a pas incrémenté la version du client Duniter (0.8.0), il faudra le faire sérieusement et publier des releases notes dans le futur pour savoir précisément quelle version utilise quoi. Je croyais que c’était simplement un hexadécimal en ascii, mais vu ce que tu as, il semblerait que non !
Je pensais plutôt dans l’autre sens; si par exemple mon noeud est ajouté dans les bootnodes et que l’on met à jour avec le nouveau bootnodes tous les noeud existants, est-ce que j’aurais du coup plus de peers ?
Ou d’un autre point de vue, est-ce que l’on peut vérifier quels nodes sont actuellement dans le bootnodes et est-ce que ce sont seulement ceux-là qui ont plus de 10-11 peers connectés ?
Mais normalement, être dans les bootnodes ne devrait pas générer d’asymétrie dans le réseau. Ils sont juste utilisés pour la découverte du réseau de proche en proche, et n’ont ensuite aucun rôle particulier.
Pas sur sur ce soit utile ou pas, mais dans les 10 bootnodes actuels; j’en retrouve 7 dans la telemetry, et ils sont effectivement parmis ceux qui ont le plus de peers:
En fait c’est plutôt dans l’autre sens que ça s’est passé : j’ai recensé les nœuds “stables” avec une bonne configuration réseau (et donc généralement beaucoup de pairs) et je les ai ajoutés aux bootnodes. Pour les autres nœuds, je n’ai pas pu récupérer d’adresse publique fonctionnelle, donc ils ont moins de pairs car uniquement les connexions sortantes. Et comme ils ne sont pas joignables, je ne les ai pas ajoutés aux bootnodes. Bien entendu, il peuvent toujours ouvrir des connexions vers les nouveaux nœuds qui arrivent avec une bonne configuration réseau.
Et oui, les modifications de topologie du réseau sont lentes. Il se peut que le réseau attende de voir un nœud en ligne pendant suffisamment longtemps pour faire monter sa note de confiance et établir une connexion stable avec lui. J’ai plus appris via la doc ipfs que via la doc substrate à ce sujet. Ce serait intéressant de creuser davantage mais ce n’est pas dans mes priorités actuellement, voilà pourquoi je me contente d’une compréhension partielle.
