Sakia 0.33.0 - Compatibilité WS2P


#1

Bonjour à tous,

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.

Les releases se trouvent toujours sur le github puisque je ne peux pas encore faire de livraison Windows via notre GitLab : https://github.com/duniter/sakia/releases/tag/0.33.0rc1

J’espère que vous apprécierez ! :slight_smile:


#2

À chaud, je ne ressens pas vraiment de différence.

C’est censé être sensiblement plus rapide ?


#3

Les ralentissements sont censés disparaitres surtout :slight_smile:


#4

J’ai quand même ressenti une vitesse sensiblement plus rapide en particulier sur la vue réseau ou c’était devenu ingérable.


#5

J’ai laissé tourner 1h30, il a synchronisé la blockckhain du 17/12/2017 au 31/01/2018… j’ai fini par fatiguer…


#6

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.


#7

Oui j’ai remarqué que les synchro ont ralenti.

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.

Je vais travailler dessus.


#8

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


#9

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)


#10

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.


#11

Bonsoir,

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é.

Très bonne soirée à tous.


#12

Un message a été intégré dans un sujet existant : Comment se faire connaître pour être certifié en étant expatrié


#13

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… :frowning:


#14

Voici les erreurs de sakia 0.33.0 rc3


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'

#15

Sur quel réseau ?

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.


#16

@Inso je vais essayer ça !


#17

ça reste extrêmement lent… en 0.33.0rc3 aussi…


#18

oui 1h pour synchroniser mon compte membre
je viens d’en ajouter un autre non membre cette fois, ça devrait aller plus vite, ah ben c’est fait : 5 mn

Le time remaining est largement sous-estimé


#19

@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.


#20

Oui, il faudra attendre les travaux de nanocryk pour aller plus loin dans des mécanismes de vérification plus rapide. :slight_smile:

J’ai corrigé les builds pour windows : https://github.com/duniter/sakia/releases/tag/0.33.0rc4