Ceci est une traduction automatique. L’original en anglais est ici: Update 20 October, 2022
Cette semaine @joshuef apporte des nouvelles sur l’avancement des comms (communications entre nœuds). Comme les lecteurs patients le savent, cela a été un blocage pendant un certain temps maintenant, mais nous voyons une lumière certaine au bout de ce tunnel particulier.
Mise à jour générale
Petit tour d’horizon de ce que fait l’équipe.
@anselme a enquêté sur une attaque par clé non autorisée qui affecte certaines autres implémentations de BLS et a découvert que la nôtre est également vulnérable. Il a soumis un correctif à la caisse blsttc. Il étudie également un bogue qui empêche les clients de rejoindre le réseau lors des tests.
@chriso travaille sur la signature des blocs et des registres, où les données (ou son Xorname dans le cas du bloc) sont signées par les anciens pour les rendre valides sur le réseau.
En relation avec cela, @bochaco apporte des modifications à l’API client liée aux commandes et aux morceaux, et débogue les erreurs qui leur sont liées sur CI.
Mostafa est occupé sur des cas de test pour notre mécanisme de consensus, et @bzee continue de pousser à qp2p, où nous pensons qu’il y a une faille profonde qui affecte la connectivité.
Progression des communications
Donc, une chose sur laquelle nous travaillons est de supprimer notre code de réduction de connexion et de nous fier uniquement au code « quinn » sous-jacent pour supprimer les connexions après un délai d’attente plus court. De cette façon, nous supposons moins, et ne devinons plus ce qui est ouvert et quand.
Lors de nos tests, cela a eu un impact positif sur les tests des clients, supprimant la probabilité que nos connexions soient fermées en cours de route.
Bi-flux
En parallèle, nous nous efforçons également de rationaliser les communications client/nœud à l’aide de flux bidirectionnels. Cela signifie que nous supprimons une partie de la complexité de la gestion de l’état et que nous attendrons simplement * une réponse des anciens. Auparavant (il y a longtemps dans le monde des nœuds), nous utilisions ce type de flux pour communiquer avec les clients, mais la gestion du flux de réponse était un cauchemar compliqué. Mais maintenant, le nœud est beaucoup plus simple (en raison du travail effectué au cours de la dernière année et demie environ), et c’est beaucoup plus gérable.
Réduction des tentatives
Nous avons également cherché à supprimer tout ce qui couvrait ces problèmes (comme nos abstractions de communication comme mentionné ci-dessus), ainsi que les tentatives de la couche client. Nous avons maintenant des messages ACK (accusé de réception) (ils ont été introduits il y a quelques mois), au client. Ceux-ci nous aident à savoir quand une commande a été vue par les anciens. Mais nous étions toujours en train d’interroger jusqu’à ce qu’un morceau soit renvoyé. @bochaco a cherché à être plus strict ici… n’autorisant pas les tentatives et disant simplement « nous avons vu le ACK… alors pourquoi ne voyons-nous pas le succès la première fois? ». Cela a exposé quelques erreurs de lecture/écriture de fichier. (Il semble que la désérialisation des commandes de stockage peut prendre plus longtemps que les requêtes… donc même si elles sont envoyées après, nous les traitons d’abord).
Réduction des charges de traitement des nœuds
Dans un effort pour réguler plus correctement la gestion des commandes de nœud, nous avons précédemment ajouté du code qui * aurait dû * organiser les messages entrants et les commander pour le traitement. Nous avons en fait vu que cela n’avait pas l’impact que nous recherchions * du tout * (en fait, cela a simplement déclenché le traitement de tous les messages les uns après les autres, quelle que soit leur priorité).
La suppression de ce code a permis une grande simplification des nœuds. Plus important encore, nous avons pu déplacer la gestion des processus de nœud hors thread sans verrou (après que notre push à thread unique ait supprimé la grande majorité du code de verrouillage).
Impact
Auparavant, nous pouvions suivre les messages entrants, mis en file d’attente pour traitement, traités puis mis en file d’attente pour envoi. Ce processus sous charge pourrait prendre un temps considérable. Parfois, c’était relativement rapide, moins d’une seconde. Parfois, avec tout le traitement des commandes et les E/S de messagerie… cela peut prendre 20 secondes.
Maintenant, nous voyons des messages arriver régulièrement aux nœuds, être traités immédiatement et des messages sortir en moins d’une milliseconde.
C’est beaucoup plus proche de ce à quoi nous nous attendions de nos communications auparavant, et cela ressemble beaucoup à la bonne direction.
Prochaines étapes
Nous cherchons à intégrer pleinement les flux bidirectionnels dans les clients, en supprimant une grande partie de la gestion de l’état. Et nous viserons également à avoir ce même flux dans les communications aîné-> adulte où des réponses sont requises, ce qui devrait encore simplifier les choses là-bas aussi. Cela devrait en fait permettre à nos messages ACK de refléter également le stockage des adultes, plutôt que de simplement dire aux anciens qu’ils ont vu un message, ce qui devrait également aider en cas d’échec des vérifications.
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é!