Sakia 0.33.0rc1 est sortie aujourd’hui. Elle apporte un changement majeur, qui va permettre à sakia de retrouver un peu de fougue. Les quelques utilisateurs ont du s’apercevoir de lenteurs ces derniers temps qui étaient dues à deux facteurs principaux :
A un réseau qui croit beaucoup : le développement de sakia a eu lieu principalement pre-ğ1, quand le réseau ne dépassait pas les 30 nœuds. Avec les centaines de noeuds actuels, l’algorithme utilisé a vite atteint ses limites
Des bugs des librairies utilisées par sakia. Elles seront proprement corrigées dans une version ultérieure, en attendant, j’ai utilisé un contournement pour que ces bugs ne gènent pas l’utilisateur.
La 0.33.0rc1, pour régler ces soucis, apporte la compatibilité WS2P ! Dorénavant, sakia ne va plus se connecter à plusieurs dizaines de noeuds pour évaluer le consensus réseau. À la place, le client se connecte à 6 noeuds aléatoires, et fusionner les résultats de l’url /network/ws2p/heads pour se faire une idée la plus large possible de l’état du consensus.
Pour détailler le principe de fonctionnement de sakia (cf la question de @gas2000 sur un autre topic) :
Sakia récupère les nœuds natifs, présents dans le fichier root_servers.yml à la racine de l’installation
Depuis ces nœuds natifs, Sakia récupère les fiches de pair du réseau.
Sakia requête les heads WS2P sur 6 noeuds. Seuls les heads WS2P correspondant à une fiche de pair connue localement sont pris en compte.
Lorsque Sakia effectue une requête, il va la réaliser sur environ 10 noeuds. À partir de 6 confirmations (6 nœuds qui s’accordent sur une même réponse), la donnée est considérée valide
En conséquence, au premier lancement, Sakia peut parfois être un peu agressif avec le réseau car il ne connait pas assez de nœuds. Il faut parfois patienter un peu avant d’avoir un network tout vert.
Pour ma part, je vois une sacrée différence. Il faut dire que ma connexion dépote pas mal aussi… mais avant c’était lent, même sur une bonne machine, mais là c’est fluide, en tout cas chez moi.
Je pense avoir compris d’ou ça vient. Il y a beaucoup (BEAUCOUP) de noeuds avec BMA incorrectement configuré. Sakia se prends les pieds dans le tapis, car une grande part de ses requêtes échouent à cause de ça.
Il est synchronisé sur 12h34 aujourd’hui (heure où j’ai ajouté mes identités) et il est 17h40.
Il ne synchronise que lorsque j’ajoute une identité. Ensuite plus rien.
DEBUG:node:request_ws2p_heads:[BoZP6] Could not connect to any BMA endpoint
L’icône de rafraîchissement en bas à gauche est elle en train de tourner ? Normalement sakia se synchronise tout seul, sans avoir à ajouter de compte. Essaye d’attendre un peu, ça peut mettre du temps (cf mon post précédent)
Il tourne puis il ne tourne plus et ne met pas à jour.
En fait je vais utiliser Césium parce que si à chaque fois que je veux vérifier une donnée en 30 secondes il me faut attendre 2 jours, ça va pas.
Suis un peu à la traîne, occupé ces deux derniers jours.
Merci beaucoup @Inso pour les explications.
Est-ce que ces dernières évolutions auraient également des implications pour le logiciel Duniter ?
Une sensation, en tout cas sur mon ordi, de davantage de vélocité.
Release de la 0.33.0rc3. J’ai revu un peu l’algorithme de Circuit Breaker que j’utilise. Dorénavant :
Au delà de 3 erreurs lors des requêtes, le noeud est considéré “offline” par sakia (en rouge dans le réseau)
Sakia tentera quand même de requêter un noeud offline en plus de 3 noeuds online lorsqu’il fera ses requêtes, afin de vérifier si il est revenu ou non
Si le noeud diffuse une nouvelle fiche de pair, sakia fera là aussi remonter le noeud en vert, jusqu’à ce que des requêtes échoue à nouveau
La vérification ne s’appuie plus sur 6 noeuds mais sur 3 noeuds
La vérification ne s’appuie plus uniquement sur les noeuds membres. C’est un rééquilibrage entre sécurité et performances… A voir vos retours.
J’ai aussi revu l’algorithme d’affichage de la WoT. C’était devenu là aussi inutilisable avec l’agrandissement du réseau et des certifications. Auparavant, je requêtais les données d’identités sur tous les certifieurs/certifiés affichés. Dorénavant, que la personne ait 25 ou 5 certifications, ça prendra le même temps d’affichage, je n’utilise plus que les données présentes dans les requêtes certifiers-of , certified-by , lookup .
A noter que j’ai un problème avec les releases Windows, qui ont arrêté de fonctionner. Ca va me prendre du temps à analyser…
Task exception was never retrieved
future: <Task finished coro=<BlockchainService.handle_blockchain_progress() done, defined at sakia/services/blockchain.py:54> exception=AttributeError("'NoneType' object has no attribute 'currency'",)>
----
Traceback (most recent call last):
File "asyncio/tasks.py", line 240, in _step
File "sakia/services/blockchain.py", line 71, in handle_blockchain_progress
File "sakia/services/identities.py", line 477, in handle_new_blocks
File "sakia/services/identities.py", line 466, in parse_block
File "sakia/services/identities.py", line 409, in _parse_certifications
File "sakia/data/processors/certifications.py", line 35, in drop_expired
AttributeError: 'NoneType' object has no attribute 'currency'
C’est très étrange comme bug. Tu devrais supprimer les connexions concernant des identités et les rajouter à nouveau. Je pense que dans la version précédente, avec le Circuit Breaker mal calibré, ça a intégré des données incorrects dans ta base.
@Inso, ça marche j’ai donc supprimé le dossier .config/sakia et relancé, je n’ai plus de messages d’erreur intempestifs et la synchro se fait régulièrement. Merci.
