# Bêta-test Duniter 1.6 WS2P

**URL:** https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247
**Category:** WS2P
**Tags:** ws2p
**Created:** [18 September 2017 16:28 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247 "2017-09-18T16:28:51Z")
**Posts on this page:** 20
**Page:** 2

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [19 September 2017 20:52 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/21 "2017-09-19T20:52:00Z")

</div>

@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 ?

---

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [19 September 2017 21:06 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/22 "2017-09-19T21:06:22Z")

</div>

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"
  ],
```

---

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [19 September 2017 23:24 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/23 "2017-09-19T23:24:37Z")

</div>

> [@cgeek](#):
>
> Oui, certainement parce qu’il faut utiliser le nom de domaine

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

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 06:38 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/24 "2017-09-20T06:38:15Z")

</div>

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é :

- @inso : [http://gtest.duniter.inso.ovh/network/ws2p/info](http://gtest.duniter.inso.ovh/network/ws2p/info)
- @elois : [http://5.135.188.170:10900/network/ws2p/info](http://5.135.188.170:10900/network/ws2p/info)

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.

> [@elois](#):
>
> @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 ?

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

```json
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.

---

<div class="post-metadata">

### Author: ![Inso](https://forum.duniter.org/user_avatar/forum.duniter.org/inso/32/1229_2.png) [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [20 September 2017 06:55 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/25 "2017-09-20T06:55:37Z")

</div>

> [@cgeek](#):
>
> 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é :
> 
> @inso : [http://gtest.duniter.inso.ovh/network/ws2p/info](http://gtest.duniter.inso.ovh/network/ws2p/info)
> 
> @elois : [http://5.135.188.170:10900/network/ws2p/info](http://5.135.188.170:10900/network/ws2p/info)

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 :

```auto
./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 ?

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 07:04 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/26 "2017-09-20T07:04:37Z")

</div>

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](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](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 :  
 ![](https://forum.duniter.org/uploads/default/original/2X/e/eb68aff905675f5a3fe3b5477f2e6e6adf1ea65e.png)

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 08:27 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/27 "2017-09-20T08:27:41Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Inso](https://forum.duniter.org/user_avatar/forum.duniter.org/inso/32/1229_2.png) [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [20 September 2017 10:07 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/28 "2017-09-20T10:07:34Z")

</div>

Ok !

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

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 10:10 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/29 "2017-09-20T10:10:54Z")

</div>

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 :

![](https://forum.duniter.org/uploads/default/original/2X/4/46e92c54d0281b0dcfc9541f1d31cea16306e5d1.png)

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

---

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [20 September 2017 15:24 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/30 "2017-09-20T15:24:10Z")

</div>

> [@cgeek](#):
>
> 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.

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](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 :

 ![](https://forum.duniter.org/uploads/default/original/2X/9/94933cde00f6f2bceef4eb4ddc1a5b7a5ab847b6.png)

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é ?

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 15:52 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/31 "2017-09-20T15:52:39Z")

</div>

> [@elois](#):
>
> 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

Je ne peux répondre que pour cette URL là : [http://5.135.188.170:10900/network/ws2p/info](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.

---

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [20 September 2017 16:08 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/32 "2017-09-20T16:08:09Z")

</div>

> [@cgeek](#):
>
> 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.

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 🙂

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 16:26 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/33 "2017-09-20T16:26:13Z")

</div>

# 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 ?

 ![](https://forum.duniter.org/uploads/default/original/2X/b/bdb0495690d960da3d9174a679eba77eb874be7d.png)

## 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é.

 ![](https://forum.duniter.org/uploads/default/original/2X/7/73929d419a3dcc2a36b051abc27b79696917788f.png)

## 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 :

- ajout des commandes :

- 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](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.

---

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [20 September 2017 17:03 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/34 "2017-09-20T17:03:59Z")

</div>

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 ?

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 17:19 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/35 "2017-09-20T17:19:28Z")

</div>

Ah si la commande doit toujours exister ! D’ailleurs je l’utilise sur ARM et [g1-test.cgeek.fr](http://g1-test.cgeek.fr).

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 17:20 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/36 "2017-09-20T17:20:37Z")

</div>

> [@elois](#):
>
> je t’ai ajouter dans ma privileged list pour tester 😉

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.

---

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [20 September 2017 17:35 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/37 "2017-09-20T17:35:24Z")

</div>

> [@cgeek](#):
>
> Ah si la commande doit toujours exister ! D’ailleurs je l’utilise sur ARM et [g1-test.cgeek.fr](http://g1-test.cgeek.fr).

~~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é 🤔

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2017 18:20 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/38 "2017-09-20T18:20:54Z")

</div>

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

```
bin/duniter direct_webstart
```

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [21 September 2017 11:40 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/39 "2017-09-21T11:40:24Z")

</div>

# Nouvelle version 1.6.4

## Fonctionnalités

- Réseau

## Correctifs

- Liés à WS2P :

- Indépendants :

---

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [21 September 2017 14:16 UTC](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247/40 "2017-09-21T14:16:35Z")

</div>

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](https://hastebin.com/hogocupuje)

 ![](https://forum.duniter.org/uploads/default/original/2X/6/6d5fb9667e879097057beb9afa8b1307857f4f80.png) ![](https://forum.duniter.org/uploads/default/original/2X/6/6d785a46f66e7c5b90721621f6c366f4d95392f1.png)

[Previous page](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247.md?page=1)

[Next page](https://forum.duniter.org/t/beta-test-duniter-1-6-ws2p/3247.md?page=3)
