@Leo semble avoir un problème similaire, je l’ai moi-même rencontré mais seulement à cause de ma perte de connexion Internet de plusieurs jours. De plus tout fonctionnait très bien en 1.6.11, et les versions jusqu’à la 1.6.14 ne touchent absolument pas à WS2P. Alors le problème est peut-être ailleurs, cela peut venir de l’augmentation du nombre de nœuds.
Est-ce un nœud miroir que tu utilises ?
C’est un nœud membre.
J’ai actuellement deux noeuds membre qui tournent;
-un en 1.6.13: RPI tournant depuis 1 semaines par rapport à son dernier ON/OFF. Le connected peers variant de 2 à 15.
-un en 1.6.14; RPI désynchronisé depuis cette nuit sans raison apparante. Je l’ai rebooté ce matin, il a énormément du mal à ce synchroniser. Sur la page web, il est au bloc 70437 actuellement en partant du bloc 70425 depuis ce matin.
Ce qui est étrange c’est que l’API donne toujours le bloc 70425! D’ailleurs, quand je fais un stop/start via l’interface web, le Current block redescends à 70425 pour repartir vers le haut. Aucun Current peers, parfois juste un seul.
Nota: J’ai bien “numéroté” mes nœuds pour qu’ils soient bien reconnus distinctement par le réseau.
Essaye de n’utiliser qu’un seul nœud à la fois, mieux vaut faire simple pour commencer et éviter les perturbations.
C’est comme même étrange que l’interface web donne le Current block à 70471 alors que l’API me donne 70426…
Oui, c’est un bug. Tu peux le remonter à travers un ticket GitHub.
La synchronisation à l’air de nouveau fonctionner…
Voici un timelapse avec quelques corrections de code:
Magnifique ! Ça c’est un réseau avec une écriture partagée !
Bon, mon nœud se désynchronise de nouveau et reste au bloc 70751 alors que l’autre nœud est bien à 70763.
Dans ces conditions, il n’est pas simple de faire un timelapse sur plusieurs jours.
Mon logiciel de timelapse est limité en mémoire et ne permet pas de traiter plus de 1000 images. Connaissez-vous un logiciel libre permettant d’assembler des images png en .gif animé?
Il en existe plein : https://unix.stackexchange.com/questions/24014/creating-a-gif-animation-from-png-files
Merci.
Je vais sans doute modifier le code pour directement faire des requêtes sur la BDD et ne plus passer par l’API. Y-a-t-il un document de disponible décrivant les champs de chaque table de la BDD?
Je n’avais pas vu ce document. Merci.
Attention, a terme le format de stockage de données pourra changer. L’API elle restera surement par souci de compatibilité.
Peux-être mais je suis plus à l’aise à faire des requêtes sur une database que d’utiliser une API, certes très bien, mais que je ne contrôle pas entièrement.
Quelle serait la retro-compatibilité des noeuds qui ne souhaitent pas être mise à jour si les tables de la BDD changent dans le futur?
La rétrocompatibilité passe par une API commune, le changement du format de stockage n’est pas important. Si tu change de format de stockage, c’est parceque le logiciel le change. Mais si ton programme n’utilise qu’un format non commun, alors plus le temps va passer, moins de personnes pourront s’en servir, ce qui serait assez dommage.
Par contre tu pourrais tout à fait proposer des améliorations des API s’il te manque des informations.
Comment l’API va régir au niveau temps exclusion quand il y aurai des milliers de membres, de peer, etc par rapport à une requête SQL?
Tu ne devrais pas récupérer tous les champs d’un coup de toute manière.
L’API va masquer le fait que tu utilise une base de donnée ou un autre format de donnée. Dans le cas d’une base de donnée les appels seront les même que les tiens, donc même vitesse (si on considère que l’appel des fonctions à un temps négligeable).
L’avantage de l’API c’est que si plus tard le format de données change, ton programme fonctionnera toujours, peu importe le format.
Pourtant les champs de l’API à ce jour sont remis en cause. Donc je n’ai pas non plus l’assurance que les champs actuels de l’API seront toujours disponible