Bêta-test Duniter 1.6 WS2P

est-e que le retour de cette fonction /network/ws2p/heads est exhaustive, ou bien indique t’elle seulement les noeuds connectés au noeud interrogés ? Je n’ai pas bien compris.

Cela fonctionne comme tu me l’indiques, pas de processus ne reste. Je vois une différence avec ce qui se passe avec duniter. Quand je fais un kill sur un fils, il disparaît, alors que les processus lancés par duniter doivent être tués par un kill -9.

Elle renvoie les toutes dernières informations connues du HEAD pour chaque clé publique qui a publié cette info. Exemple sur Ğ1-Test :


{
  "heads": [
    {
      "message": "WS2P:HEAD:3dnbnYY9i2bHMQUGyFp5GVvJ2wBkVpus31cDJA5cfRpj:58767-0000D592A968A5E395C2F3834DE0793C140B76CE86CC88B35F14CE947837F2C8",
      "sig": "/DY7RhtgyHc3bsRod71vubHcwsKCjrkqyKDwa0NEtPk/kbA5qz9h9wSZRIwW+LKdPoiPg3+s/OpFNmlDrbn0DQ=="
    },
    {
      "message": "WS2P:HEAD:ES5jZNkpBanPR2575SMDmxz4sG7pucNzaf7u8Au3GG1A:58767-0000D592A968A5E395C2F3834DE0793C140B76CE86CC88B35F14CE947837F2C8",
      "sig": "93w5bHlBIWgR+QthPjFWb2+JUk1u8ssUzzMS17I67GSFE751UmZPN6frY7wI/+GuTifvVOWy5aCt3NDEADNyAw=="
    },
    {
      "message": "WS2P:HEAD:2RbXrLkmtgWMcis8NWhPvM7BAGT4xLK5mFRkHiYi2Vc7:58177-00005A2C1CFDB29B212C753E0779B805990092078623EE7E9E44044B504AF547",
      "sig": "aQx6X58h8yokMA4ZoTB2wkiN4OLe3jAOq9SaSWVUDvFhtgb0rfIsATycV7x0P6LtePEMvvDPyzfW5iqvHeakDg=="
    },
    {
      "message": "WS2P:HEAD:D7CYHJXjaH4j7zRdWngUbsURPnSnjsCYtvo6f8dvW3C:58767-0000D592A968A5E395C2F3834DE0793C140B76CE86CC88B35F14CE947837F2C8",
      "sig": "VUCaSdqjuIKrW7sFkms9ToYAVVyiOEDXCosDabO9ylHBPydvk8L1m65j7vrgb9baIn1XktnVBlmA4dBkCDHMCQ=="
    },
    {
      "message": "WS2P:HEAD:mMPioknj2MQCX9KyKykdw8qMRxYR2w1u3UpdiEJHgXg:58767-0000D592A968A5E395C2F3834DE0793C140B76CE86CC88B35F14CE947837F2C8",
      "sig": "/Jv4ZVyBCDBVUkW4I/XwKhpVYWQcK5O4t254a2jLFncBX09D5pkNUmUou/ik3XeDu/sqW8V3cgZ1XoTAoASNBw=="
    },
    {
      "message": "WS2P:HEAD:FoW1mRs6P7vHHLoetiq55rYtVkCboCM9af7B5t51NMFN:58767-0000D592A968A5E395C2F3834DE0793C140B76CE86CC88B35F14CE947837F2C8",
      "sig": "Tii2QEWEQvVJhTYM6RhGLtc4Xm3gbHre9YKPP78pjS1GKCOO7FmJUmXLIQFT7OqRH4a2XgB5kIgEJocCXFrMCQ=="
    },
    {
      "message": "WS2P:HEAD:Zbpv9GspqWgMQVBzG7ascahHJkqyNb8BEawQ9JXE2RT:58767-0000D592A968A5E395C2F3834DE0793C140B76CE86CC88B35F14CE947837F2C8",
      "sig": "evis0NrxY0qxZPI+l3EeMdKJuOv4Qhjm3YfOrs1zfJLmG7afGab2SiKSzc5IHVJex4shdrUXfpkfZ2sKq8YNAQ=="
    }
  ]
}

Ici on peut voir qu’aux dernières nouvelles, on a 6 nœuds dont le bloc courant est 58767-0000D592A. Et qu’on a aussi un nœud dont le dernier signal était d’avoir comme bloc courant 58177-00005A2C1.

Tous les nœuds WS2P propagent cette info, en broadcast avec rebond. Donc un nœud miroir est censé avoir ces infos aussi.

Tu peux modifier le fichier proof.js de Duniter pour afficher des messages dans le processus principal préalablement lancé avec duniter direct_start. Ça te permettra de déboguer un peu et savoir ce que fait le processus.

Par exemple entre la ligne 1 et 2, tu insères un messages :

console.warn(`Le fils est lancé (PID  ${process.pid})`)

Puis ligne 18-19, tu insères une autre ligne :

console.warn(`Le chargement des modules s'est bien passé (PID  ${process.pid})`)

Et ainsi de suite jusqu’à trouver un truc intéressant.

Alors je n’ai pas trouvé de truc intéressant comme cela, mais les processus fils sont bien quittés. Donc le problème se passe quand j’utilise duniter stop.

Comme je n’arrive pas à me connecter au réseau en WS2P privé, il faudra attendre que je sois chez moi pour ouvrir des ports et tester en WS2P public. Je ne peux donc pas voir si duniter continue calculer de vieux blocs.

As-tu tenté un commentaire ligne 49-50, du genre :

console.warn(`Annulation demandée, est-on en train de calculer ? ${!computing.isFulfilled()} (PID  ${process.pid})`)

Ou carrément ligne 36-37 :

console.warn(`Commande IPC : ${message.command} (PID  ${process.pid})`)

Si tu laisses ton nœud tourner suffisamment longtemps, ça te permettra d’en savoir pas mal sur le cycle de vie effectif de les processus de preuve. Et moi de comparer avec ce qui est attendu :slight_smile:

Oui alors ce problème vient du fait que le réseau Ğ1 est encore peu déployé en WS2P, alors au démarrage ton nœud ne trouve pas de quoi se connecter (je viens de vérifier). Le réseau Ğ1-Test est plus adapté pour l’instant.

Bon du coup je viens de tester mon conseil sur le Raspberry PI, car je reproduis le même problème :

Commande IPC : conf (PID  24696)
Commande IPC : newPoW (PID  24696)
Commande IPC : conf (PID  24702)
Commande IPC : newPoW (PID  24702)
Commande IPC : conf (PID  24714)
Commande IPC : newPoW (PID  24714)
Commande IPC : conf (PID  24708)
Commande IPC : newPoW (PID  24708)

Je vois aussi des info: Cancelling the work on PoW cluster mais non suivis d’un Commande IPC: cancel qui pourtant devrait apparaître. D’ailleurs je ne vois pas plus de Commande IPC : newPoW normalement consécutive à une annulation qui se poursuit avec une nouvelle preuve, ce qui me fait dire que c’est toute la communication IPC qui est coupée.

Je continue …

J’ai finalement trouvé deux problèmes :

  • le CPU à 100%
  • la communication IPC “coupée”, à cause du CPU 100% (en réalité elle n’est pas coupée, mais n’a plus de temps processeur pour répondre)

Cela vient d’une cadence trop haute de calcul, le fait d’avoir un tour de preuve en 100ms est trop élevé pour des cartes aussi faibles en puissance, relativement au travail cryptographique demandé et aux traitements annexes qui sont faits (traitement normal des identités, transactions, etc).

J’ai testé avec des tours à 500ms (presque 100ms par cœur en fait), et j’ai à peu près la calibration demandée du %CPU utilisable. Bon c’est vraiment pas terrible car c’est du doigt mouillé, mais expérimentalement je constate à peu près la bonne valeur. En tout cas même si la correspondance n’est pas parfaite entre %CPU demandé et réel, on peut ajuster la valeur %CPU pour atteindre la valeur réelle désirée.

J’essaie ensuite de trouver une solution au problème de @stephane (Livrables ARM en attente : Raspberry PI 3 HS) puis je fais une version.

3 Likes

Bonne nouvelle. Merci pour tous tes efforts !

Nouvelle version 1.6.5

Correctifs

  • Liés à WS2P :

    • correction d’un bug majeur qui empêchait de télécharger les blocs manquants lors de la résolution de fork
    • le message « WS2P >> Streamer >> WS2P connection timeout » s’affichait de très nombreuses fois dans les logs
    • Duniter ne fonctionnait pratiquement plus sur les Raspberry PI et autres cartes ARM
      • le CPU était toujours à 100% d’utilisation
      • la preuve de travail calculée traitait presque toujours le même bloc
      • le message « The proof-of-work generation was canceled: Document already under treatment » s’affichait de très nombreuses fois dans les logs
  • Indépendants :

    • il était devenu impossible d’ajouter manuellement la WebUI avec yarn add duniter-ui

cc @elois, @Alan_Schmitt, @stephane, @SimonLefort

Lien de téléchargement : https://github.com/duniter/duniter/releases/tag/v1.6.5

4 Likes

Mise a jour effectuée sur g1-test.elois.org :slight_smile:

1 Like

Je teste ça dès demain matin! :slight_smile:

Merci! Et n’oublie pas de dormir aussi.

Merci pour tous ces efforts !

Je teste (sur ğ1-test), et visiblement j’ai une erreur de clé à un moment :

2017-09-26T08:41:29+02:00 - info: WS2P 79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux: new incoming connection from 192.168.0.254:35507!
2017-09-26T08:41:29+02:00 - trace: WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1-test:79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux:9795bae6-90a4-43b9-aa1b-efd593ca5703409803d5-ddfb-4365-800b-1e52c2d390cc
2017-09-26T08:41:29+02:00 - trace: WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1-test:79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux:9ccf4186-76e5-4be5-973f-5967cb5a963bb6ee25b0-1d8f-4783-b91c-b2e1da034ace
2017-09-26T08:41:29+02:00 - error: WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE
2017-09-26T08:41:29+02:00 - trace: WS2P >>> registerCONNECT >>> WS2P:CONNECT:g1-test:79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux:9ccf4186-76e5-4be5-973f-5967cb5a963bb6ee25b0-1d8f-4783-b91c-b2e1da034ace
2017-09-26T08:41:29+02:00 - trace: WS2P >>> sendACK >>> WS2P:ACK:g1-test:79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux:9ccf4186-76e5-4be5-973f-5967cb5a963bb6ee25b0-1d8f-4783-b91c-b2e1da034ace
2017-09-26T08:41:29+02:00 - error: WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE
2017-09-26T08:41:39+02:00 - info: WS2P: Could not connect to peer -------- using WS2P 78.242.14.140 10090: WS2P connection timeout
2017-09-26T08:41:39+02:00 - debug: WS2P: init: failed connection
2017-09-26T08:41:39+02:00 - warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout

J’ai l’impression que c’est la connexion à moi-même qui échoue. (L’IP à la fin est mon IP publique.)

Oui le cas est troublant, à surveiller.

Nouvelle version 1.6.6

Correctifs

  • Liés à WS2P :

    • le démarrage réseau de la partie WS2P était bloquant pour les autres services
    • WS2P Public est désormais activé par défaut pour les nœuds disposant d’UPnP
    • sécurité : contrôler la bonne forme des push de données HEADs (état du réseau)

Lien de téléchargement : https://github.com/duniter/duniter/releases/tag/v1.6.6

Il s’agit d’une Release Candidate !

2 Likes

Soit dit en passant, le réseau Ğ1 est déjà bien fourni en nœuds WS2P : au moins 9 nœuds connectés actuellement !

1 Like

Arf je ne vois plus le miens :’(

hum … j’ai du loupé quelque-chose, je n’ai que deux connexions ws2p sur mon nœud mais je vois bien tous les autres :confused:

C’est peux-être le même problème:
https://forum.duniter.org/t/livrables-arm-en-attente-raspberry-pi-3-hs/3249/63

je suis pas sur arm mais j’avais un soucis sur ma conf apparemment

avant

{
“uuid”: “afaa79d8”,
“privateAccess”: true,
“publicAccess”: true,
“upnp”: false,
“host”: “duniter.help-web-low.fr”,
“port”: 7777,
“remoteport”: 7777,
“maxPublic”: null
}

après

{
“uuid”: “afaa79d8”,
“privateAccess”: true,
“publicAccess”: true,
“upnp”: false,
“host”: “151.80.40.148”,
“port”: 7777,
“remoteport”: 7777,
“maxPublic”: null,
“remotehost”: “duniter.help-web-low.fr
}