Bêta-test Duniter 1.6 WS2P

elois · 19 September 2017 20:52

@cgeek si je souhaite tester un 2ème nœud sans bma connecté en WS2P privé avec mon 1er noeud, comment je fait pour initier la connexion ?
Puisque mon noeud local n’a pas bma comment je lui dit de prévenir un autre nœud qu’il l’invite ?

elois · 19 September 2017 21:06

Bon pour tester le multi-noeud j’ai lancé un 2ème noeud local sans bma et avec la config automatique pour ws2p, il reçoit bien les nouveaux blocs et arrive a calculer !
D’ailleurs sont endpoint WS2P est apparu sur la fiche de peer de mon 1er noeud : Ça semble très bien fonctionner tout ça

// http://g1-test.elois.org:10900/network/peering

{
  "version": 10,
  "currency": "g1-test",
  "endpoints": [
    "WS2P 0078b390 89.92.72.40 20903",
    "BASIC_MERKLED_API g1-test.elois.org 5.135.188.170 2001:41d0:8:c5aa::1 10900",
    "WS2P 3eaab4c7 g1-test.elois.org 10920"
  ],

elois · 19 September 2017 23:24

Chez moi ça fonctionne avec l’ip : http://5.135.188.170:10900/network/ws2p/heads

cgeek · 20 September 2017 06:38

Oui mais si tu es sous YunoHost tout passe par le Nginx qui ne route que par NDD. Je pense que c’est le cas d’Inso et Vincentux.

En tout cas vos nœuds fonctionnent parfaitement en WS2P Public/Privé :

Quoi que pour toi Eloïs je ne peux pas vérifier la connexion WS2P Privé, il n’a aucun nœud auquel il est connecté par ce biais actuellement.

Tu as deux options que tu peux mettre dans le fichier de conf, qui sont des listes de clés publiques :

ws2p: {
  preferedNodes: [],
  alwaysAccept: []
}

Le paramètre preferedNodes définit les clé publiques prioritaires en accès privé, tandis que alwaysAccept définit celles prioritaires en accès public.

Donc si tu ajoutes des clés publiques dans preferedNodes, ton nœud essaiera de s’y connecter en priorité au démarrage (vrai que dans Duniter 1.6.3) et aussi tentera de maintenir coûte que coûte une connexion privée déjà établie avec cette clé.

À noter que si l’on a plusieurs nœuds avec la même clé publique, toutes les connexions de cette clé seront effectuées.

Si tu ajoutes des clés publiques dans alwaysAccept, alors ton nœud essaiera de maintenir au maximum une connexion publique déjà établie avec ton nœud, et si jamais cette connexion arrive plus tard alors que ton nœud est déjà saturé en connexions publiques, il tentera d’en ferme une moins prioritaire à son profit.

À noter que si l’on a plusieurs nœuds avec la même clé publique, toutes les connexions venant de cette clé seront acceptées.

Je vais faire une nouvelle version 1.6.3 dans la journée.

Inso · 20 September 2017 06:55

Alors je ne comprends pas du tout comment ça marche !

J’ai configuré WS2P sur un port différent de BMA (7777). Nginx ne fait aucune redirection sur WS2P (d’ou le fait que je testais directement par l’IP).

cf la conf utilisée :

./bin/duniter config --ws2p-noupnp --ws2p-port 7777 --ws2p-host 37.187.192.109 --ws2p-remote-port 7777 --ws2p-remote-host 37.187.192.109

Tu as une idée de pourquoi ça marche ?

cgeek · 20 September 2017 07:04

Oui, c’est simplement qu’il existe 3 notions à distinguer :

WS2P Privé, qui est juste un client WebSocket, donc traffic sortant : aucune conf requise. Ça justemarche.
WS2P Public, que tu as paramétré sur le port 7777 et qui n’est pas une API servie sur un chemin web (donc pas consultable via un chemin /ws/jenesaisquoi contrairement à BMA)
BMA, qui peut t’informer éventuellement de ce que fait WS2P

Dans ton cas, http://37.187.192.109:7777/network/ws2p/heads n’est pas une URL pour WS2P mais pour BMA, en ce qu’elle contient un chemin web. Elle ne fonctionne pas à plusieurs titres :

tu utilises une URL BMA sur le port de WS2P
si tu voulais consulter BMA, c’était plutôt à l’URL http://gtest.duniter.inso.ovh/network/ws2p/heads
si tu voulais vérifier le fonctionnement WS2P, il aurait plutôt fallu le faire avec SimpleWebSocketClient avec pour adresse ws://37.187.192.109:7777 :

cgeek · 20 September 2017 08:27

J’ai deux notions dont j’aimerais trouver un nom correct :

les nœuds auxquels on souhaite se connecter en priorité : je suis parti sur le nom preferedNodes
les nœuds qu’on souhaite privilégier s’ils se connectent à nous : je suis parti sur le nom privilegedNodes

Si vous avez meilleur noms, je peux encore les changer. C’est juste pour de la conf.

Inso · 20 September 2017 10:07

Ok !

Dernière question, pourquoi BMA répond pour WS2P ?

cgeek · 20 September 2017 10:10

Pour que Sakia, Cesium et Silkaj aient une échappatoire pour afficher le réseau complet tout en restant sur BMA.

edit : d’ailleurs j’ai oublié de citer une 3ème URL de websocket spécifique à BMA, afin de suivre l’évolution du réseau remonté par WS2P :

Comprenez bien que c’est une béquille, en attendant de bien belles API les clients.

elois · 20 September 2017 15:24

Alors c’est là que c’est flou pour moi, j’ai un 2ème nœud membre sans bma qui arrive bien a suivre les blocs et calculer graçe a WS2P. Comme c’est la même clé l’endpoint WS2P apparait magiquement sur la fiche de peer de mon 1er nœud, qui lui a BMA d’activé : http://g1-test.elois.org:10900/netork/peering

Ce que je ne comprend pas c’est comment est géré le cas de noeuds avec la même clé par WS2P, d’après ma web-ui mon deuxième noeud n’est pas connecté au premier :

Ce que je voudrais en fait c’est créer une connexion WS2P privée entre mes deux nœuds membres, mais si je comprend bien :

À noter que si l’on a plusieurs nœuds avec la même clé publique, toutes les connexions de cette clé seront effectuées.

Pourtant la connexion entre mes deux nœuds n’est pas visible, ni sur la web-ui du 2-ème neoud ni sur l’api bma du 1er, alors qu’en est t’il en réalité ?

cgeek · 20 September 2017 15:52

Je ne peux répondre que pour cette URL là : http://5.135.188.170:10900/network/ws2p/info qui indique ce nœud (physique) n’a pas de connexion privée mais est bien connecté en P2P à 4 autres nœuds.

Mais avec l’impression d’écran pour ton deuxième nœud : on voit qu’il est connecté à 3 nœuds par liaison privée.

Dans cette version 1.6.2, il me semble que deux nœuds jumeaux (c’est-à-dire partageant la même clé) ont du mal à de se connecter l’un à l’autre à cause du conflit de clé partagée.

Mais j’ai un comportement plus clair en 1.6.3, qui est en cours de livraison.

La connexion entre jumeaux peut désormais s’effectuer sans problème, mais dans la limite des possibilités techniques : un nœud WS2P public peut être contacté, mais un jumeau qui n’aurait que WS2P privé ne pourrait pas l’être. Toutefois ce dernier peut initier la connexion vers son jumeau public. Le raisonnement peut s’étendre à N jumeaux, mais viennent ensuite les limites de nombre de connexions (paramétrable également).

Ça, c’est pour la connexion “familiale”. Mais pour le reste du réseau ? Dans ce cas on ne considère qu’une seule connexion d’un des nœuds jumeau. Par exemple pour un nœud A qui aurait reçu une connexion avec J1, alors si J2 tente de se connecter à A il sera refusé. J2 peut aller tenter sa chance ailleurs avec B par exemple, qui n’aurait aucun J connecté à lui.

Il y a aussi une règle de « maximisation des connexions publiques » : tout nœud va tenter d’élaguer ses connexions privées au profit de ses connexions publiques. À cet effet si un nœud C avait établi une connexion privée vers J2 et que J3 décidait de se connecter à C, alors C accepterait la connexion J3 et élaguerait la connexion J2. J’introduis ici J3 car bien évidemment, comme J2 a déjà une connexion publique vers lui-même il ne va pas tenter de créer une connexion privée vers C en vertu de la règle de maximisation.

Alors tout cela demande à être testé et vérifié, mais je ne pense pas m’être trompé sur grand-chose.

elois · 20 September 2017 16:08

ok c’est justement ce que je voulais tester, je confirme que mes deux nœuds ne sont pas connectés ensemble.

Et merci pour le détails ça me semble bien plus clair désormais

cgeek · 20 September 2017 16:26

Nouvelle version 1.6.3

Ajout de l’UID de membre dans la vue réseau

Afin d’y voir un peu plus clair sur qui est connecté à nous : membre ou miroir ?

Configuration WS2P par la WebUI

Il est désormais possible de configurer WS2P en majeure partie via la WebUI.

À noter qu’il est possible de totalement désactiver l’accès WS2P, aussi bien public que privé.

Autres correctifs

autoriser la connexion interne de nœuds jumeaux
les fiches de pair sans BMA sont désormais acceptées
les fiches de pair peuvent ne plus déclarer aucun endpoint (permet la suppression totale des interfaces¹)
élagage plus précis des connexions non prioritaires
contrôle que la clé réceptionnée dans la négociation de connexion est bien celle attendue
correction de l’option --ws2p-remote-host qui tronquait la valeur donnée

ajout d’options pour configurer WS2P en ligne de commande :

--ws2p-max-private <count>      Maximum private connections count.
--ws2p-max-public <count>       Maximum public connections count.
--ws2p-private                  Enable WS2P Private access.
--ws2p-public                   Enable WS2P Public access.
--ws2p-noprivate                Disable WS2P Private access.
--ws2p-nopublic                 Disable WS2P Public access.
--ws2p-prefered-add <pubkey>    Add a prefered node to connect to through private access.
--ws2p-prefered-rm  <pubkey>    Remove prefered node.
--ws2p-privileged-add <pubkey>  Add a privileged node to for our public access.
--ws2p-privileged-rm <pubkey>   Remove a privileged.

ajout des commandes :

duniter ws2p show-conf
duniter ws2p list-nodes
duniter ws2p list-prefered
duniter ws2p list-privileged

en cas d’extinction forcée (Ctrl+C), le nœud tente de terminer sa tâche d’écriture disque avant de fermer
découplage entre l’activité de preuve de travail et pull BMA
attente de la fermeture effective du serveur de WebSocket en cas de demande de fermeture

¹ : est suivie d’un ticket de sécurité : https://github.com/duniter/duniter/issues/1114

Avec la version ARM

Cette fois-ci, j’ai pu livrer la version ARM. À tester toutefois.

Dans le cas d’ARM, je conseille de définitivement couper l’interface BMA dans “Settings > Network > Enable BMA”. Cette API est devenue bien trop gourmande et inefficace pour les nœuds ARM.

elois · 20 September 2017 17:03

mise a jours sur 1.6.3 effectuée

@cgeek je t’ai ajouter dans ma privileged list pour tester

@cgeek autre question, la commande direct_webstart n’existe plus sous duniter 1.6.x ?

cgeek · 20 September 2017 17:19

Ah si la commande doit toujours exister ! D’ailleurs je l’utilise sur ARM et g1-test.cgeek.fr.

cgeek · 20 September 2017 17:20

En fait, il me semble qu’en jouant avec ces listes ainsi que les nombres max de connexions privées/publiques, ont peut créer le réseau maillé qu’on désire.

elois · 20 September 2017 17:35

~~En installation manuelle depuis les sources ça ne fonctionne pas~~ oubli, j’avais oublier que je n’est pas installer la web-ui…

EDIT : bon j’ai essayer d’ajouter la web-ui en manuel et la commande direct_webstart ne veut toujours pas se lancée :

yarn add duniter-ui
rm -r node_modules
yarn

je ne vois pas se que j’ai loupé

cgeek · 20 September 2017 18:20

Comme ça je dirais que tu n’as rien loupé, mettons que tu sois dans ~/dev/duniter, la commande est :

bin/duniter direct_webstart

cgeek · 21 September 2017 11:40

Nouvelle version 1.6.4

Fonctionnalités

Réseau
- possibilité de ne plus déclarer aucun endpoint sur sa fiche de pair, par exemple pour ne plus être contacté

Correctifs

Liés à WS2P :
- les endpoints BMAS n’étaient plus inscrits dans la fiche de pair
Indépendants :
- correction d’un bug majeur qui rendait le nœud quasi-inopérant, affichant en boucle le message The proof-of-work generation was canceled: [object Object].
- correction d’une faille potentielle où un attaquant pouvoir envoyer une infinité de fiches de pair de nœuds miroirs.

elois · 21 September 2017 14:16

Mon nœud local sur 1.6.4 reste bloqué au bloc 56070 alors qu’il est en liaison WS2P avec 3 noeuds qui eux sont au bloc 56553, ça fait plus de 30 min et il ne rattrape pas sont retard je vais devoir le resync manuellement, les log : https://hastebin.com/hogocupuje