Actualités du développement Safe 🇫🇷 7 juillet 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 7 July, 2022

Merci à Spatium pour les 4 images de titre que vous verrez utilisées au cours des prochaines semaines :heart_eyes:

Quelques nouvelles prometteuses sur le front de la chasse aux bogues alors que l’équipe a retrouvé une méchante petite créature qui provoquait des blocages lors de la réplication des données lors du roulement. Pour les esprits techniques, le bogue en question était une référence à un nœud verrouillé en lecture qui persistait même après sa suppression, et sa recherche a été rendue possible par les travaux en cours pour supprimer le multithreading et simplifier le code. En tant que tel, nous avons pensé que ce serait un bon moment pour mettre les gens au courant du travail que nous faisons dans sn_node à cet égard et sur d’autres points. @joshuef prend les commandes cette semaine.

Progrès général

@yogesh est prêt à refactoriser la base de code pour se débarrasser de SledDB. Comme mentionné dans les mises à jour précédentes, nous étions sur la bonne voie pour remplacer SledDB (pour le stockage des registres) car il avait des problèmes de limitations d’écriture et n’était pas non plus activement maintenu. Par conséquent, nous avons comparé quelques alternatives au cours des semaines précédentes, chacune ayant ses avantages et ses inconvénients. À la suite de l’analyse, l’équipe a décidé d’opter pour l’implémentation de stockage sur disque interne que nous utilisons déjà pour stocker des blocs. Il s’agit d’une implémentation keep-it-simple qui n’a pas de cloches et de sifflets et fonctionne à égalité avec les autres alternatives, tout en nous libérant également d’avoir une autre dépendance externe qui pourrait ne pas être super maintenue. Actuellement, il ne prend en charge que le stockage des blocs et doit donc être réorganisé pour prendre en charge les registres de stockage, pour lesquels le travail est bien avancé.

@qi_ma a examiné les tests de désabonnement qui ont échoué et ont été lents, en partie - nous pensons - à cause du bogue décrit dans l’introduction (et ci-dessous). De faux messages ont également été envoyés aux clients, ce qui pourrait bien faire partie du même problème.

Cette semaine également, @Heather_Burns a fait un retour triomphal après la peste au Parlement britannique, où elle a représenté MaidSafe lors d’une table ronde de petites entreprises technologiques et de start-ups qui risquent d’être des dommages collatéraux dans la détermination du gouvernement à réglementer Internet autour de Facebook. Heather rapporte que les députés qu’elle a rencontrés sont parmi les rares à «comprendre cela» et à vouloir empêcher que cela ne se produise, alors j’espère que notre message a été entendu haut et fort. Par inadvertance, elle a peut-être aussi détruit le gouvernement. Oups.

État du nœud

Beaucoup de gens se demandent peut-être quel est l’état actuel du nœud et pourquoi nous avons entrepris certaines tâches.

Voici un petit aperçu de l’état des nœuds :

Moins de serrures

Au cours des dernières semaines, nous avons déplacé le nœud vers une configuration à un seul thread. Cela n’a apparemment pas eu beaucoup d’impact sur les performances (bien que cela ait un peu amélioré les choses), mais le but ici était de simplifier la base de code. Avec un seul thread à prendre en compte (par défaut… nous pouvons toujours en générer d’autres si nécessaire), nous n’avons pas besoin d’autant de freins et contrepoids dans le code pour lui permettre de fonctionner de manière simultanée.

L’exemple le plus clair de ceci est la possibilité de supprimer les RwLocks (verrous en lecture-écriture) de la base de code. Ces petites structures permettent au code d’attendre qu’une donnée donnée ne soit pas modifiée sur un autre thread, avant de la modifier. Soigné!. Oui. Mais aussi dangereux. Bon nombre des bogues et problèmes récents que nous avons résolus dans sn_node sont dus à ces attentes qui durent indéfiniment (une situation que nous appelons un blocage).

C’est ici que le passage à sn_node à thread unique brille vraiment, car nous pouvons supprimer la grande majorité d’entre eux de la base de code, et avec eux, nous supprimons toute une classe de bogues (et vraiment pénibles à déboguer aussi !). Ainsi, non seulement le code est plus propre, plus clair et plus sain, mais il devrait être moins sujet aux erreurs au démarrage !

Nous sommes à environ 80 % du chemin à travers cela maintenant. Après avoir supprimé beaucoup de verrous sur les structures de « nœuds » internes et les avoir remplacés par un verrou de niveau supérieur, il est beaucoup plus facile de raisonner (bien que la transition ait généré un autre blocage !). Un bon exemple des améliorations de la simplicité se traduisant par la vitesse peut être vu dans certains de nos https://maidsafe.github.io/safe_network/dev/bench/

C’est une grosse victoire.

Réseaux de test

Un autre domaine dans lequel nous avons travaillé pour améliorer les choses, et nous continuerons à le faire, est les testnets et le débogage. Certaines erreurs de testnet ont été le résultat d’une infrastructure défaillante, par exemple, disons que nous avons démarré une gouttelette DigitalOcean, mais que le nœud n’a pas démarré correctement là-bas pour une raison quelconque. Les modifications récentes ont rendu les redémarrages de nœuds plus stables, ainsi que le nettoyage du code en boucle en arrière-plan, ce qui devrait tous aider dans des situations comme celle-ci.

Nous cherchons également à améliorer la situation de la journalisation, avec des journaux Cmd plus clairs à sortir séparément des journaux d’exécution plus détaillés. Ceux-ci devraient être plus faciles à analyser pour les gens et, espérons-le, nous pourrons les connecter à l’instance ElasticSearch que nous avons pour les réseaux de test internes.

Adhésion

L’adhésion continue de s’améliorer, bien qu’elle ait été retardée par le seulinterrupteur fileté. Nous cherchons à combler l’écart entre ce que les nœuds comprennent et votent, et ce qui est partagé au sein d’un SectionAuthorityProvider (SAP). Cela devrait également améliorer la stabilité.

Dysfonctionnement

Une autre classe de bogues que nous abordons maintenant est une classe de bogues un peu plus « méta » - les nœuds qualifiant d’autres nœuds de dysfonctionnels (et donc hors ligne). Bien faire cela est délicat (quand un nœud est-il dysfonctionnel par rapport à un mauvais moment temporaire ?). Cette douleur est ressentie avec acuité sur l’intégration continue (CI), où les machines sont moins puissantes, et on peut donc parfois voir des nœuds être votés hors ligne, ce qui peut casser un cycle de test…

À cette fin, nous avons récemment étendu les suites de tests dans sn_dysfunction et cherchons à continuer à les développer et à les améliorer, pour arriver à des situations reproductibles où nous pouvons savoir que des votes hors ligne se produisent à cause de nœuds défectueux.

Mémoire et CPU

Avec les changements de thread unique, la récente refonte de la republication des données et avec quelques simplifications dans la base de code du nœud sn_node fonctionne généralement très bien, avec une utilisation moyenne de la mémoire d’environ 130 Mo pour un aîné (sur un Mac; testnet local), ~ 70 Mo pour adultes.

À l’heure actuelle, tous les gros pics sont des drapeaux rouges clear pour nous, et c’est un endroit vraiment agréable car cela permet de trouver la cause de ces problèmes beaucoup plus facilement.

Données

La récente découverte de bogues « traîneau » a atténué le sentiment de stabilité des données, mais nous travaillons à supprimer cela en ce moment. Ce changement devrait, espérons-le, simplifier et unifier le stockage des données dans sn_node, de sorte que le comportement devrait être plus cohérent pour tous les types de données.

Et ooOOoooo…

Bien qu’il n’y ait pas toujours l’impression que les choses progressent pour la communauté étant donné que tout le monde ne voit pas ce qui est travaillé et amélioré au jour le jour, les choses vont définitivement dans la bonne direction. Chaque testnet que nous faisons tourner est plus stable (en général), mais si pour une raison quelconque il y a un bogue, avec tous ces changements récents, plus avec les statistiques des gouttelettes de suivi du serveur ElasticSearch, il devient beaucoup plus facile de voir où se situent les problèmes, et espérons que cela deviendra de plus en plus facile aussi !


Liens utiles

N’hésitez pas à répondre ci-dessous avec des liens vers les traductions de cette mise à jour de développement et les modérateurs les ajouteront ici.

En tant que projet open source, nous sommes toujours à la recherche de commentaires, de commentaires et de contributions de la communauté. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!