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é :
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 :
bin, config, data etc.) et donc avoir 2 fichier de configuration/bin/./elasticsearch -d ?Merci de ton aide
Hello @kimamila
Alors en fait, lancer 2 noeuds ES n’est pas “bonne pratique” 
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.
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 
Tu peux forcer la JVM à utiliser, via la variable d’environnement JAVA_HOME, en l’exportant, avant de lancer ./elasticsearch
Va pour ca alors !