Ceci est une traduction automatique. L’original en anglais est ici: Update 28 October, 2021
Les bogues peuvent être difficiles à trouver, plus difficiles à éliminer et parfois encore plus difficiles à expliquer. Dans ces mises à jour, nous essayons de présenter les dernières nouvelles sur les progrès que nous réalisons et nos plans pour les prochaines étapes, mais à certains égards, c’est la partie facile. Comme dire que nous progressons régulièrement dans une certaine crique sans dire à quelle distance se trouve notre destination, combien de pagaies nous avons à notre disposition, et en ignorant les crocodiles, les rapides et autres désagréments qui se trouvent sur le chemin. Le plus dur est d’expliquer ces insectes sans se perdre dans les mauvaises herbes. C’est un sale boulot, mais dans l’intérêt de fournir le contexte indispensable, quelqu’un doit passer au crible les journaux. @joshuef a tiré la courte paille.
Progrès général
L’API et le code CLI ont maintenant été fusionnés dans le référentiel principal Safe Network, bien qu’il n’y ait pas encore de nouvelle version car certains tests CLI échouent. Le processus de libération doit également être ajusté pour prendre en compte les ajouts à ce repo. @Chriso est sur l’affaire.
La suppression du pool de connexions de qp2p est également très proche, avec cette fonctionnalité prise dans Safe Network où nous pouvons l’affiner. Le pool de connexions a maintenu les connexions client ouvertes, mais d’une manière difficile à affiner et à configurer comme nous le souhaitons. Le supprimer simplifie qp2p et supprime beaucoup de cas extrêmes - et presque certainement beaucoup de bogues.
Pendant ce temps, @Joshuef a éliminé un énorme bloqueur cette semaine, réussissant à réduire la charge de messages dans certaines circonstances (entre bons nœuds), de ~ 65 000 à ~ 500, tout va bien.
@bochaco et @yogesh se sont penchés sur la façon dont les sections gardent une trace les unes des autres, comment ce processus peut être rendu plus efficace, et où et dans quel format ces informations sont stockées.
Et @Lionel.faber a cherché à hiérarchiser les types de messages. Certains messages sont plus importants que d’autres. Les messages BLS DKG, qui gèrent l’autorisation, doivent être prioritaires. Rien d’important ne devrait arriver sans l’accord des anciens. Libérer les canaux pour ces messages accélérera tout. À l’autre extrémité du spectre, les requêtes, les commandes de données et les messages d’erreur peuvent attendre leur tour avec bonheur sans affecter les performances.
Bugs
Je ne pense pas que quiconque ait jamais prétendu que Safe était simple. Ce n’est pas. Mais ce n’est pas pas non plus. Nous avons les pièces présentées comme les gens l’ont vu dans divers réseaux de test. Et depuis le dernier (qui, nous savons il y a quelque temps), nous nous sommes efforcés de tout rendre plus stable.
Les bogues à l’origine de l’instabilité sont souvent abordés dans les mises à jour, mais de manière assez technique. Donc, ici, nous voulions donner un peu plus d’un aperçu général. Quelque chose d’un peu plus accessible aux gens qui n’aiment pas plonger dans un éditeur de texte pendant des heures.
Vous avez vos bugs classiques
2+2=5
Ou des messages supprimés entre les nœuds (votre message n’arrive pas).
Ou un problème de connexion, où la plupart de ce que vous voulez arrive. Mais la vis dont vous avez besoin n’est pas passée. (Et maintenant, vous devez essayer de faire en sorte que cela se reproduise, afin que vous puissiez voir pourquoi cette vis n’arrive pas.)
Les conditions de concurrence, c’est-à-dire qu’un problème ne peut survenir que si un code ou un programme se termine plus rapidement qu’une autre partie du système. (Alors peut-être que vous ne le voyez que si votre cheval LuckyProblems arrive juste avant SinonWeWork et juste après ThisAlreadyHappened ; mais tout autre combo se passe bien).
Boucles. Les choses continuent de se produire parce qu’elles déclenchent des choses à la fin. Peut-être pour toujours. Ils provoquent souvent un blocage ou un plantage direct de tout, car ils continuent à utiliser les ressources du programme.
Bloque. Également connu sous le nom de blocages. Ces bugs sont le Catch 22 du monde des bugs. Vous ne pouvez continuer que si vous avez number=5, mais vous ne pouvez définir number que si vous avez number=5. C’est évidemment un symptôme d’un bug classique, mais aussi souvent main dans la main avec quelque chose de course, donc vous ne le remarquez pas avant qu’il ne soit trop tard (et maintenant vous ne savez pas vraiment pourquoi cela se produirait… : pensée:.)
Ensuite, vous avez plus de détails sur le Safe
Qui ne sont souvent que des symptômes de ce qui précède…
Amplification des messages. C’est à ce moment-là que nous pouvons nous attendre à recevoir 5 messages via nos nœuds de stockage, mais à la place, nous en obtenons 500. Ce qui à son tour fait revenir 15 000 autres. Il y a normalement un bogue là-dedans (2+2=5) lorsque nous voyons cela, ou il se peut que le système ne fasse pas ce que nous pensions donc nous devons repenser la conception. (Nous avons récemment envoyé naïvement des tentatives AE à tous les anciens. Pour aggraver cela, la prochaine série de nouvelles tentatives serait donc envoyée par tous les anciens… à tous les anciens. :chart_with_upwards_trend 
Parfois, nous obtenons un manque de débit. Les messages ne sont pas supprimés. Mais les choses sont lentes. Pourquoi!? Parfois une combinaison de tout ce qui précède.
Pour le moment, après quelques refactorisations, nous avons trop de débit. Maintenant, ce n’est pas un problème en soi, mais cela peut souvent exposer divers autres problèmes… (faites votre choix parmi l’un des types de bogues mentionnés dans cet article !)
Fourches ! Des fourches sur le chemin de notre connaissance de la section (qui est venu avant nous… qui engendrent qui)… si les nœuds ne le font past d’accord pour une raison quelconque (une raison boguée), eh bien, nous pouvons peut-être avoir deux ensembles de connaissances valides, mais ne savons pas lequel est réellement pertinent pour notre situation actuelle.
Données non trouvées. C’est une évidence… mais pourquoi ? Eh bien, tout ce qui précède pourrait conduire à ce que les données ne soient pas réellement PUT en premier lieu. Alors bonne chance pour trouver ce qui n’existe pas !
Pas de division ! Nous avons besoin de divisions pour maintenir le réseau en bonne santé (pour diviser la charge de travail plus facilement et maintenir la résistance aux piratages, par exemple). Ne pas diviser pourrait être un bogue dans l’algorithme DKG (Distributed Key Generation… Ou comment nous donnons à nos aînés leur autorité).
Choisir la mauvaise cible. Parfois, le système de messagerie semble fonctionner et le colis est livré. Mais nous l’avons en fait envoyé à la mauvaise personne (ou à tout un quartier/une section !?).
Être trop excité ! Parfois, nous faisons quelque chose dès que nous le pouvons. Mais le réseau, dans son cheminement nécessaire vers une cohérence éventuelle, n’est pas encore prêt. (Imaginez que vous mettez un morceau, mais que tout n’a pas encore été stocké, mais que vous essayez déjà d’obtenir.) Il peut sembler qu’il y ait un bogue. Mais en fait, si vous réessayez dans quelques secondes, peut-être que tout est là et que tout va bien. Vous pensiez avoir un bug, mais vous étiez juste trop vif.
SooOOooo
Donc. C’est un petit aperçu de diverses choses que nous pouvons voir et rencontrer dans le système. Cela peut être par nœud, par client ou par section… Et seulement parfois, ou seulement un mardi sur une version obscure de Linux. Et lorsque vous voyez le problème, il peut se cacher au-delà de 3 ou 4 types de bogues différents, avant d’arriver à la racine du problème.
Tout cela que nous examinons dans un système de 45 nœuds et de plusieurs clients (en moyenne pour le moment lors des tests internes).
Le coffre-fort n’est pas si complexe quand on y pense, du moins conceptuellement (partage des données entre ordinateurs). Mais ce n’est pas non plus aussi simple que cela pourrait l’être, c’est pourquoi nous continuons à résoudre les problèmes, à refactoriser les choses (les rendre plus simples) ainsi qu’à implémenter de nouvelles fonctionnalités (et parfois elles visent carrément à aider à déboguer).
La suppression du code inutile et de la complexité nous aide à obtenir quelque chose de simple, qui, en plus de résoudre vos bogues classiques dans le système, est souvent l’un des moyens les plus importants de résoudre les bogues. Moins de code, moins de problèmes. 
Nous y arrivons ! Cela ne semble pas toujours rapide, mais nous avons toujours l’impression que nous avançons (même lorsque nous devons parfois reculer un peu).
Liens utiles
- Site Web du réseau sécurisé
- Safe Network Primer
- Principes de base du réseau
- Feuille de route
- Glossaire
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é!