Manque de places WS2P sur le réseau Ğ1!

[matograine]

@vit

Es-tu sûr de modifier le bon fichier de config ?

Oui. D’ailleurs:

• j’ai fait mes derniers changements en passant par la cli
• ils sont pris en compte (mon peering change)

@Pini

Est-ce que tu n’aurais pas un endpoint défini en plus dans la section endpoints ?

En BMA, oui.

Peering

$ curl http://5.51.176.238:19001/network/peering

{
  "version": 10,
  "currency": "g1",
  "endpoints": [
    "BASIC_MERKLED_API 5.51.176.238 19001",
    "WS2P bb5e697f 5.51.176.238 19002 /",
    "WS2P 9ec40ddc 5.51.176.238 10900 /"
  ],
  "status": "UP",
  "block": "417442-00000035BA5B873F755873D310D2E07508F5E0ED75F5AF07CAD09145CB235AD3",
  "signature": "1ppm15zwy6USTGc6NEatfyRA1omN/xErATnaZtmNz2Ae5o1S7ZtFf+5kqdfQha/t/pwsyqnzWor5tEIrIF45BQ==",
  "raw": "Version: 10\nType: Peer\nCurrency: g1\nPublicKey: CmFKubyqbmJWbhyH2eEPVSSs4H4NeXGDfrETzEnRFtPd\nBlock: 417442-00000035BA5B873F755873D310D2E07508F5E0ED75F5AF07CAD09145CB235AD3\nEndpoints:\nBASIC_MERKLED_API 5.51.176.238 19001\nWS2P bb5e697f 5.51.176.238 19002 /\nWS2P 9ec40ddc 5.51.176.238 10900 /\n1ppm15zwy6USTGc6NEatfyRA1omN/xErATnaZtmNz2Ae5o1S7ZtFf+5kqdfQha/t/pwsyqnzWor5tEIrIF45BQ==\n",
  "pubkey": "CmFKubyqbmJWbhyH2eEPVSSs4H4NeXGDfrETzEnRFtPd"
}

---

J’ai vérifié :

• le bon port est configuré sur mon NAT. remote et local.
• le parefeu est activé, les bons ports (19001, 19002) sont ouverts

[Pini]

Je parlais de la section endpoints du fichier de configuration. Voici la mienne :

  "endpoints": [],

Et voici mes endpoints vus de l’extérieur :

$ curl https://duniter.pini.fr/network/peering
{
  "version": 10,
  "currency": "g1",
  "endpoints": [
    "BMAS duniter.pini.fr 37.187.116.209 443",
    "WS2P ccb989cf duniter.pini.fr 443 websocket/ws2p"
  ],
  "status": "UP",
  "block": "417373-00000011B363E0897D9FF0471EC6B520B15B3D36F28E4B742F6EBF8234397E93",
  "signature": "/vLS0/wHtXQGr6iC/NcmShoX076d6a90AcD/fJ8UqAkjyFNeGtiJXzYMprE79Kz9fM7R3qTO/GbH0C49Tg9ZDg==",
  "raw": "Version: 10\nType: Peer\nCurrency: g1\nPublicKey: 9R9VtA9fpCHbTNHztMAjYfwyV5PFWDKgPygXun7C4VPC\nBlock: 417373-00000011B363E0897D9FF0471EC6B520B15B3D36F28E4B742F6EBF8234397E93\nEndpoints:\nBMAS duniter.pini.fr 37.187.116.209 443\nWS2P ccb989cf duniter.pini.fr 443 websocket/ws2p\n/vLS0/wHtXQGr6iC/NcmShoX076d6a90AcD/fJ8UqAkjyFNeGtiJXzYMprE79Kz9fM7R3qTO/GbH0C49Tg9ZDg==\n",
  "pubkey": "9R9VtA9fpCHbTNHztMAjYfwyV5PFWDKgPygXun7C4VPC"

[matograine]

Ah. Ben j’ai la même que toi, vide.

fichier de config

{
 "currency": "g1",
 "endpoints": [],
 "rmEndpoints": [],
 "upInterval": 3600000,
 "c": 0.0488,
 "dt": 86400,
 "dtReeval": 15778800,
 "ud0": 1000,
 "stepMax": 5,
 "sigPeriod": 432000,
 "sigReplay": 5259600,
 "sigValidity": 63115200,
 "msValidity": 31557600,
 "sigQty": 5,
 "xpercent": 0.8,
 "percentRot": 0.67,
 "powDelay": 0,
 "avgGenTime": 300,
 "dtDiffEval": 12,
 "medianTimeBlocks": 24,
 "httplogs": false,
 "udid2": false,
 "timeout": 3000,
 "isolate": false,
 "forksize": 100,
 "switchOnHeadAdvance": 3,
 "nonWoTPeersLimit": 100,
 "msPeriod": 5259600,
 "storage": {
  "transactions": true,
  "wotwizard": false
 },
 "loglevel": "info",
 "cpu": 0.6,
 "nbCores": 2,
 "prefix": 1,
 "nobma": false,
 "bmaWithCrawler": true,
 "upnp": false,
 "dos": {
  "whitelist": [
   "127.0.0.1"
  ],
  "maxcount": 50,
  "burst": 20,
  "limit": 40,
  "maxexpiry": 10,
  "checkinterval": 1,
  "trustProxy": true,
  "includeUserAgent": true,
  "errormessage": "Error",
  "testmode": false,
  "silent": false,
  "silentStart": false,
  "responseStatus": 429
 },
 "ws2p": {
  "uuid": "bb5e697f",
  "privateAccess": true,
  "publicAccess": true,
  "preferedOnly": false,
  "privilegedOnly": false,
  "upnp": false,
  "port": 19002,
  "remotehost": "5.51.176.238",
  "remotepath": "/",
  "maxPrivate": 4,
  "maxPublic": 15,
  "sync": true,
  "privilegedNodes": [
   "A5LQXCkx8b6rzppfqdqeHbKPDGmKZtRcqwxP4BSeag5r"
  ],
  "remoteport": 19002
 },
 "proxiesConf": {
  "reachingClearEp": "clear",
  "forceTor": false
 },
 "sigStock": 100,
 "sigWindow": 5259600,
 "idtyWindow": 5259600,
 "msWindow": 5259600,
 "rootoffset": 0,
 "udTime0": 1488970800,
 "udReevalTime0": 1490094000,
 "remoteport": "19001",
 "ipv4": "192.168.1.29",
 "port": "19001",
 "remoteipv4": "5.51.176.238",
 "remotehost": null
}

[vit]

Encore moi avec encore une remarque, sur le SSL cette fois.

Duniter considère qu’une connexion est en SSL si le port est 443 (pour BMA en tout cas). n’y aurait-il pas un problème pour Duniter à déterminer si une connexion doit se faire en SSL ou pas si les ports ne sont pas 443 ?

[lciviero]

J’ai fait un mauvais script python tout moche vite fait : https://github.com/lciviero/ws2p_tester

***************
*** RESULTS ***
***************
  DateTime: 2021-04-22 11:44:23.927719
  End points tested: 37
  End points ok: 12
  Error timeout: 18
  Error bad status: 4
  Error https invalid: 3

[poka]

Mon WS2P fonctionne très bien, c’est ton plugin qui aime pas les extension .legal

[Pini]

Un noeud qui est plein est censé répondre quoi ? Timeout, bad status, ou invalid ?

[elois]

@fdrubigny

Sans changer ma configuration qui me semble opérationnelle, j’ai testé comme indiqué avec l’extension préconisée et le endpoint répond apparemment…

@fdrubigny ton endpoint déclaré est wss://duniter.adn.life et non pas wss://duniter.adn.life/ws2p. Tu utilite un path sans le déclarer, forcément ça ne peut pas fonctionner. Tu dois déclarer ton path avec l’option --ws2p-remote-path , relis la doc c’est indiqué

@tuxmain

A-t-on pensé à faire un DDOS sur les nœuds Duniter, juste en squattant les connexions WS2P ?

Non. L’anti-ddos c’est le fait que les membres sont prioritaires. Si un attaquant surcharge le réseau, les nœuds membres pourront toujours se relier sans problèmes, les nœuds miroir invités comme privilégiés sur certains nœuds s’en sortiront aussi. Seuls les nœuds miroirs invités nulle part subiront l’attaque.

@lciviero

Idem ma configuration est bonne normalement, mais le nœud freeze de temps en temps,

En effet toi c’est un problème d’intermittence, est ce que tu manques de RAM ? Où la bande passante de ton serveur est saturée ?

@matograine

Le port public indiqué dans la conf est 19002 (et mon NAT est bien configuré)

Pourtant ws://5.51.176.238:19002 ne répond pas.

@matograine

C’est comme si mon noeud Banana Pi avait enregistré la config pour mon noeud Laptop… Ou p-ê est-ce le reste d’une ancienne config…

C’est à cause des **** de fiches de peer partagées. Il te faut supprimer l’ancien endpoint «à la main» : doc/use/advanced-commands.md · dev · nodes / typescript / duniter · GitLab

Aussi pense à supprimer ton remotePath (string vide).

@vit

n’y aurait-il pas un problème pour Duniter à déterminer si une connexion doit se faire en SSL ou pas si les ports ne sont pas 443 ?

Oui, Duniter passera en wss:// uniquement si le port est 443. !Ce qui est conforme aux spec des websocket, car comme leur nom l’indique c’est du web, c’est une surcouche du protocole HTTP, donc c’est les normes de HTTP qui doivent être utilisés.

@Pini

Un noeud qui est plein est censé répondre quoi ?

Il est censé répondre comme un nœud qui n’est pas plein. Le quota s’applique à posteriori et pas à priori. Il y a un élagage des connexions les moins prioritaires chaque fois que le quota est dépassé.

[elois]

@lciviero

J’ai fait un mauvais script python tout moche vite fait

Ce qui serait utile, c’est que ce script liste les endpoint en erreur et pour chaque endpoint en erreur indique la clé publique de la fiche de peer qui le déclare. Ça permettrait de savoir qui contacter

[fdrubigny]

@elois

@fdrubigny ton endpoint déclaré est wss://duniter.adn.life et non pas wss://duniter.adn.life/ws2p. Tu utilite un path sans le déclarer, forcément ça ne peut pas fonctionner. Tu dois déclarer ton path avec l’option --ws2p-remote-path , relis la doc c’est indiqué

Normalement, c’est bon, j’ai corrigé, si tu veux bien vérifier, merci

[elois]

non c’est pas bon, tu peut constater sur ta fiche de peer que le remote path n’apparaît pas :

https://duniter.adn.life/network/peering

[lciviero]

Je vais voir pour modifier le script et implémenter ta demande

Concernant mon nœud aucun problème de ram (185Mo used / 2Go), disque (ssd local), ou réseau (presque pas de trafic). A la limite de CPU, car l’host mine un peu de crypto

Je suis en train de grapher les latences de mon nœud pour voir l’ampleur du phénomène.
(10 probes par minute espacé de 5s avec timeout de 5s sur BMA, BMAS, Admin et WS2P)

Un volontaire pour que je rajoute son nœud à titre de comparatif ?

[fdrubigny]

cette fois-ci il apparaît, je n’avais pas relancé le noeud… Oops !

[elois]

Dsl c’est toujours pas bon, tu à indiqué comme remote path duniter.adn.life/ws2p au lieu de ws2p

[fdrubigny]

Bon cette fois-ci je « pense » que c’est bon…

[elois]

Oui, cette fois ci le endpoint que tu déclares est bien cohérent avec ce qu’attend ton reverse proxy

[lciviero]

Ca à l’air bon de ce que je vois, j’ai testé tes ep ws2p et BMAS

[lciviero]

Voila ce que ca donne : Latence nœud duniter

• BMA, on voit beaucoup de timeout chaque point qui n’est pas vert c’est qu’il y a entre 1 et 9 timeout sur 10 requêtes et quand il y a des trous ca veux dire aucune réponse sur les 10 probes soit pendant 50 secondes… Aïe
• BMAS n’a pas de timeout vu que c’est le proxy http qui répond
• WS2P pas de timeout mais je ne fais qu’un test basic en http, je ne test pas le websocket

[fdrubigny]

Ok @elois & @lciviero ! Merci

[vit]

il y a peut-être un réel souci sur la gestion asynchrone des requêtes par nodejs pour BMA… Peut-être que cela vaudrait le coup que tu mettes en correspondance les timeouts avec les logs de ton nœud Duniter…

My two cents…