Beta-test Duniter4j (ElasticSearch API) 0.16.1 > avec synchronization P2P!

Donc je n’arrive pas a joindre cette adresse http://localhost:9200/g1-test/block/current

mais dans les logs j’ai vu cette ligne :

j’ai donc essayé avec mon adresse ip : ws://163.172.178.252:9402/ et j’obtiens ça :

Cette ligne indique que le serveur de websocket et lancé sur la port 9402 (pour info, joignable uniquement si tu met ws://163.172.178.252:9402/ws/<chemin_valide> sinon ca réponds pas).
Mais un autre serveur (HTTP cette fois) a du être lancé (plus haut dans les logs) sur 9200 (ou 920* en fonction des ports déjà occupés).

Sur cette machine, comment fais tu pour accéder aux autres service (duniter, etc), depuis chez toi ? As tu un reverse proxy nginx, ou ouverture de port directe sur les port locaux ?

ok, ça doit être 9202, sur cette ligne alors ?

Yes !

Nouvelle version : duniter4j-es-0.17.1.
Plusieurs anomalies remontées lors des 1er tests y sont corrigés.

@elois, a priori le problème de JDK n’a rien à voir avec ton soucis.

Fonctionnement

  • Au démarrage du noeud ES, une synchronisation est faite à partir des noeuds Duniter déclarant les API ES_USER_API et ES_SUBSCRIPTION_API dans leurs endpoints.
    • Il est également possible de configurer un liste figée de endpoints, et de désactiver le crawler.
  • A la fin de la 1ere synchronisation, une WebSocket est ouverte pour écouter tous les changement du noeud, qui sont alors reporté sur le noeud (après vérification du respects des règles des documents : signature, hash, etc.)
  • Toutes les heures, les connexion WebSocket sont fermées, pour :
    • Actualiser la listes des endpoints du réseau (détection des nouveaux endpoints dont l’API est compatible)
    • Relancer une synchronisation sur ces endpoints (uniquement un delta à partir de l’heure des documents, en appliquant toutefois une marge d’erreur sur l’heure) ;
    • puis on réouvre les WebSockets

etc.

N’hésitez pas à commenter/questionner cette solution.

Ğ1 > 2 noeuds Cesium+/ES !

Nouvelle étape importante pour Cesium+ : un 2ème noeud ES vient de débuter sa vie ! Les 2 noeuds discutent bien entre eux : jusqu’ici l’entente est cordiale ! :wink:

Ce 2ème noeud, fonctionne de manière complètement autonome de g1.duniter.fr, sur un autre serveur :

note : j’ai désactivé (par configuration) la découverte dynamique de nouveaux noeuds ES, pour reste “en famille” pour le moment. Mais rien n’empêche d’ajouter vos noeuds, branchés sur les miens.

Bref, enfin un déjà début de décentralisation de mes travaux ! ^^
J’espère que d’autres pourront me rejoindre ? @elois ? @vincentux ?

Et pourquoi pas @cgeek et @Florck sur duniter.org ? (…mais peut-etre faut-il attendre un peu avant)

3 Likes

ok je retesterai avec ma JVM Oracle dés que je peut, si c’est pas demain soir ce sera le soir d’après :slight_smile:

1 Like

Grâce à une nuit de synchronisation entre les noeuds ES, j’ai détecté un bug majeur dans Cesium+ (bug non détecté par les noeuds ES): le timestamp des documents Json (messages, profiles, etc.), c’est à dire la propriété time, n’était pas toujours incrémenté par Cesium.
Or ce champ permet des synnchronisations différentielles entre noeuds, par comparaison des “versions” du document (pour déterminer le plus récent).

j’ai donc du :

  • Côté Cesium : corriger le bug, afin de mettre à jour systématiquement le champstime;
  • Côté ES : ajouter une règle de contrôle, afin que time > previous_time

Vous allez surement me dire : “mais comment tu peux utiliser une heure, si elle est donné par le client ? elle n’est pasdigne de confiance !”. La solution mise en oeuvre est simple :

  • le noeud ES autorise un décalage maximal (configurable) du time, dans des documents reçus;
  • lors d’une synchro différentiel, on interrroge les autres noeuds en premant un délai de sécurité : potentiellement trop de documents sont ramenés, mais on fait ensuite un tri est fait à l’aide de time : sont ignoré les documents déjà à jour ou plus anciens.

En effet, je n’utilise pas l’heure blockchain, à cause du problème des rollbacks qui risquerait de rendre invalide des documents de l’utilisateur.

Bref, l’heure indiqué dans les documents n’est pas “exact” mais bien celle fournie par le client, mais on s’en fiche car ces données ne sont peu critiques :wink:

N’hésitez pas à me faire des remarques/critiques.

EDIT: mieux vaut donc ne pas utiliser encore le noeud ES g1.data.le-sou.org. Je vais devoir le resynchroniser complètement

Oui tout à fait !

C’est pas plutôt un décalage minimal ? Dans le sens où le nœud Cesium+ refuse un document qui serait signé à un intervalle trop court par exemple.

Oui bien. Je rajouterai “le nœud Cesium+ refuse tout document dont la date/heure UTC+0 est supérieure à l’horloge locale UTC+0, avec acceptation d’une marge d’erreur de 10 minutes (par exemple)”.

Pour éviter le spam, c’est ca ? Par exemple mise à jour trop rapide d’un même doc ?
Je n’y avais pas pensé, mais pourquoi pas oui.

Non, je parlais d’une erreur maximale autorisée dans l’heure. Par exemple, si le noeud est à 12h00 (UTC+0) alors il acceptes les documents avec un time compris entre 11h50 et 12h10 (UTC+0).

Cela dis, à cause des problèmes d’horloge, je penses qu’on peut même accepter +/- 1 heure, non ?

non, pas dans le cas d’une synchronisation depuis un autre noeud ES, car il peut très bien à avoir une coupure réseau longue. A moins que tu voulais parler de la synchro directe, par WebSocket ? Pour celle-ci oui, je pourrais ajouter le contrôle de time.

En résumé :

  • le web crawler qui se lance toute les heures est plus souple sur les heures.
  • les controles sur le champ time sont appliqués au plus tôt, lors dela communication avec le client : soit à la réception par l’API GET/POST, soit par la réception par WebSocket.

Oui. Enfin ça ne te gêne peut-être pas plus que cela pour les nœuds Cesium+.

Une coupure réseau même de quelques jours n’implique pas un décalage horaire de plusieurs minutes ! C’est important de refuser les documents écrits dans le futur par rapport à l’heure indiquée par ton nœud, sinon c’est la porte ouverte à une attaque de spam.

A oui effectivement pour les dates dans le futur on peut les refuser. C’est seulement pour les dates du passé qu’on ne peut pas, sans risquer de perdre une partie des données. Pour ce cas là, il faudra peut-etre passer par un quota / utilisateur, je ne sais pas…

@florck question ES : quelle est la bonne pratique pour lancer 2 noeuds ES sur la meme machine :

  • Faut-il dupliquer toute l’installation (répertoire bin, config, data etc.) et donc avoir 2 fichier de configuration
  • Faut-il avoir une seule installation, et simplement lancer plusieurs fois /bin/./elasticsearch -d ?

Merci de ton aide

Hello @kimamila
Alors en fait, lancer 2 noeuds ES n’est pas “bonne pratique” :wink:

Mais si tu as une bonne raison de le faire (par exemple ton serveur à plus de 32G de RAM) dans ce cas, il faut faire 2 installations complètement distinctes, le mieux serait alors de containeriser (docker / lxc) pour permettre une bonne séparation des ressources.

1 Like

En fait, j’avais pensé faire cela pour les mises à jour sans interruption de service… en ayant besoin d’une seule machine. (et par failover nginx)
Tu vois le truc ? Comment t’y prendrais tu @florck ?

en fait pour ça effectivement ce serait d’avoir un cluster multi-node et donc sur des machines différentes de façon préférentielle. Car ce que tu veux est de la HA (high availability).

Sinon pour ton besoin précis, tu peux toujours redémarrer un elasticsearch dans un conteneur sur la même machine alors que le elasticsearch de ton host tourne toujours.

Mais c’est un peu usine à gaz…

Bon, je penses que la v0.18.2 de duniter4j est la bonne, niveau synchro P2P !

J’ai 2 noeuds parfaitement synchronisés (en production !) => démo sur https://g1.le-sou.org

Qui peux/veux tester ?
pour l’installation : on dézippe et on lance la commande <HOME>/bin/elasticsearch. Vous serez directement en prod : toutes les données Cesium+ en redondance parfaite chez vous !

(Pour que le noeud ES soit visible dans la vue réseau Cesium, il faudra ensuite ajouter des endpoints.)

EDIT: @elois, si pas ou peu d’inscriptions pour l’atelier de dev Cesium+, reste il de la place dans les jours techniques pour présenter cela. C’est à dire présentation des évolutions techniques Duniter4j/Cesium+, et démo de la synchro P2P ?

J’ai tenté l’installation, je suis tombé là-dessus :

./bin/elasticsearch
Exception in thread "main" java.lang.IllegalStateException: duniter4j-es-core requires Java 1.8:, your system: 1.7

J’ai donc installé openjdk-8-jre, mais j’ai toujours le même message.

Ça demande certainement plus d’investigations, mais je n’ai pas trop de temps devant moi dans l’immédiat.

Oui il y a toujours le créneau de jeudi de 16h à 17h :wink:

Tu peux forcer la JVM à utiliser, via la variable d’environnement JAVA_HOME, en l’exportant, avant de lancer ./elasticsearch

Va pour ca alors !

1 Like