Il me semble que la centralisation des requêtes par défaut sur le noeud Duniter g1.duniter.org commence a faire monter en charge ce serveur.
Je crois que c’est @cgeek qui l’administre?
Je pense que nous aurions intérêt à mettre ce domaine en DNS roundrobin pour répartir la charge sur un peu plus de noeuds…
Avec @elois, @poka, @kimamila, @yann et d’autres? Que diriez-vous d’établir une liste de ces serveurs à mettre en load balancing.
Ou alors inscrire en dur une liste de tous les serveurs souvent connectés, et ne les utiliser que pour actualiser cette même liste puis piocher des serveurs au hasard pendant l’utilisation, un peu comme Tor. Ça éviterait la centralisation par les propriétaires du nom de domaine.
Par contre il faudrait implémenter ça dans tous les logiciels.
Excellente idée @tuxmain, en plus c’est déjà possible sans modifier Duniter, seule les logiciels clients ont besoin d’être modifiés.
Pour une telle liste en dur il faudrait un engagement clair des personnes dont le noeud est inscript concernant l’url de leur noeud. Perso a terme mon noeud Duniter sera déplacé sur ts.g1.librelois.fr et y restera pour une durée indéterminée 
Et puis même si le noeud en question finit par tomber ou n’est pas toujours en ligne, le client devrait pouvoir se reconnecter à un autre noeud de la dite liste pour continuer.
Il faudrait aussi modifier duniter pour que lors de sa première synchro un nœud ne soit pas dépendant d’un seul autre.
Pour constituer la liste automatiquement il faudrait mesurer leur taux de disponibilité dans le dernier mois par exemple, donc soit ajouter la liste des nœuds à chaque bloc dans duniter.db, soit passer par un service extérieur qui va enregistrer chaque heure la liste des nœuds disponibles et à jour. On ne peut pas se contenter de prendre la fenêtre courante ou les derniers auteurs de blocs car cela mettrait de côté les nœuds miroirs.
J’ai développé deux systèmes de calcul distribués pour mon travail et j’ai intégré dès le départ une répartition de la charge.
Dans le premier, ce sont les agents de calcul qui ont un montant de jobs maximum simultanés. Si l’agent est complet, le client refait une recherche sur tous les agents à intervalles réguliers, jusqu’à trouver un agent libre à qui soumettre le job en attente.
Dans le cas de Duniter, en fonction du débit réseau, du cpu, et d’autres critères, le nœud pourrait limiter les accès à un certain volume de requêtes (mais je crois que c’est déjà le cas). Le client devant alors chercher dans la fiche de pair un autre nœud.
En fait cela pose tout de même la question des clients mono serveur !
C’est dommage de créer un réseau p2p et de se connecter uniquement sur un nœud. Comme si on faisait des clients bittorrent qui téléchargent toujours sur le même seed ??!!
Sakia interroge plus de six nœuds qu’il choisit aléatoirement, avant de décider de la bonne branche.
Si tous les clients adoptaient une méthode de requêtes décentralisées ont aurait pas ce problème. J’invite les développeurs de client à ajouter une issue pour implémenter ça. peut-être dans la librairie API.
Tiens ça me donne envie d’implémenter ça dans Duniterpy, la gestion multi-nœud, pour fournir aux clients Python une information vraiment décentralisée et leur permettre d’écrire sur des nœuds pris au hasard, en simplifiant leur code…
C’est ce que fait Sakia pour info Il serait intéressant de l’implémenter dans Cesium.
C’est une super idée, ça faisait partie de ma todolist d’extraire ça de Sakia pour le mettre dans la lib, mais ça demande pas mal de boulot Si tu le refais à zéro, puis tu adaptes Sakia à ce moteur réseau, c’est peut être une meilleure approche !
Duniterpy va devenir incontournable (pour les clients Python) avec ça :
@tuxmain en fait la synchro est déjà en p2p. Un noeud duniter ne dépend pas d’un seul autre. Il récupère des morceaux de blockchain auprès de tout les nœuds du réseau qu’il arrive a joindre. Le noeud indiqué en paramètre est seulement celui qui va indique le blockcstamp cible = la version de la blockchain qui fait foi.
Et ce choix doit être manuel car l’utilisateur doit impérativement choisir un noeud de référence en lequel il a confiance. SI une majorité de noeuds se mettent a mentir sur le réseau (ce qui est une attaque facile a mettre en place pour qui a les moyens) alors le choix manuel d’un noeud de de référence comme fait actuellement résiste très bien a cette attaque. Alors qu’une automatisation serait exposée a une tel attaque, et surtout ça n’apporterai aucune plus value par rapport au fonctionnement actuel. La synchro est déjà bien répartie ainsi que les échange WS2P.
Le problème exposé ici ne concerne que les API Clients, donc j’insiste il n’y a rien a faire coté Duniter
Tiens j’en parlais justement recement .
Dans mon objectif de rendre fault tolerant / OnLine l’index de juniter je compte employer apache spark / hive / zookeeper.
Pour mener ce projet a terme, je cherche un volontaire pour mettre en place un cluster de raspberry pi, setup apache spark avec yarn (nonon pas le yarn de js, celui de zookeeper) et puis un ou deux noeud pour les fronts.
Ya un peu de taf, j’en suis pas encore là mais en principe une fois que c’est fait il sera possible de débrancher des raspi a chaud et de les voir se reconnecter. Après ya ptet des gens qui préféreront coder leurs architecture distribué, moi je préfère isoler le data store dans un outils type état de l’art industriel.
bref j’en suis pas encore la mais je cherche quelqu’un qui kifferais fabriquer un cluster rasberryPi que je suis prés à financer.
Perso, Silkaj crashe aléatoirement avec une erreur de timeout lorsqu’il est connecté sur g1.duniter.org.
On a atteint la limite de la centralisation.
récupère la liste des Endpoints et envois sur un autre noeud.
Qu’est-ce qui t’empêche d’envoyer la transaction à X nœuds simultanément et d’ignorer toute exception si une réponse est bonne ? c’est même plus sur pour la transaction non ?
je penses que je vais retirer g1.duniter.org de ma conf. perso j’ai mon Cesium configuré chez toi @Moul 
ton serveur est plus fluide et puis je me dis que si on te spammais tous, ça nous laissera ptet une chance de faire des blocs. 
Oui, c’est envisageable pour l’émission de documents.
Par contre, pour la consultation de donnés, il faut s’assurer d’avoir des bonnes donnés en choisissant un bon nœud. Sinon, l’idée c’est qu’avec GVA, cette vérification de partialité des donnés entre les nœuds soit faite.
Bien vu, j’avais pas capté que l’API BMA de mon nœud était accessible sur le réseau. Je m’en vais sur le champ le spammer avec mon client.
Attention à cette liste de césiums tournante.
Si je fais un cesium modifié (qui par exemple récupère la clef privée au lieu de faire générer le document en local, voir installe un virus) il faut s’assurer que je n’apparaisse pas dans la liste.
J’ai confiance en les gens derrière g1.duniter.org, je ne peux pas avoir confiance si le site renvoie sur un serveur aléatoire.
Peut-être une liste manuelle reste-t-elle préférable ?
Il peut y avoir une liste par défaut, mais il est clair qu’il faut qu’elle soit éditable, pour qu’on puisse choisir parmi quels nœuds on veut taper, effectivement…
On pourrait créer un dépôt git qui contient la liste des nœuds de référence et qui serait inclus dans les clients et nœuds via git subtree.
C’est pas le Césium qui est surchargé a mon avis, c’est juste du HTML chargé localement dans le navigateur… C’est plutôt le noeud duniter qui est derrière.
Si on ne fait tourner que le noeud, et pas le site entier, mon warning disparaît.
Mais actuellement Cesium est attaché à un noeud non ? Ce serait possible de spammer un nœud avec des requêtes sans que celui-ci n’ait donné son accord ?
Pour info, ce week end au GMarché de Noel à Toulouse, il était impossible de faire ses paiements. C’est la rançon du succès, un bonne centaine de personnes… Et une super ambiance!!!
Tout le monde utilisait Cesium quasiment.
L’idée de @vit de faire une bibliothèque qui inclue le mode P2P de cette répartition de charge me semble une bonne solution (qui détache de la propriété du domaine). Je ne me rends pas compte si c’est facile à intégrer aux clients (cesium, silkaj, sakia( c’est déjà dedans?), et g1sms…
il faut absolument que les clients repartissent la charge. spammez moul !
plus concrètement c’est pas très compliqué:
1 requête vers https://g1.duniter.org/network/peers
on extrait tout les endpoints supposément dispo en une requête. je les persistes en base mais un client peut simplement filtrer ce qu’il a besoin.
ya pleins de endpoints mal configuré donc faut filtrer !!
puis on met à jour occasionnellement avec https://g1.duniter.org/network/peering les noeuds individuel mais j’utilise uniquement /network/peers : plus facile et ça permet d’étendre ma propre vue du réseau)
D’ailleurs à ce propos quelqu’un sait-il pourquoi l’état du réseau tend a être cohérent entre tout les nœuds? est-ce normal? voulu? nécessaire?
ensuite je requêtes soit en boucle soit en parallèle, jusqu’à obtenir une réponse correct. ya aussi un merkle tree mais c’est prise de tête pour pas grand chose donc je fais sans pour l’instant
Tu configure une douzaine de nœud de départ en cas de downtime d’un serveur, tu devrais être pénards jusqu’à la fin du monde.