framboise314.fr

Pour tester ce serveur UDP, le plus simple c’est de créer un client. On peut chiader un peu le truc pour filtrer ce qui arrive sur le port du serveur (ici j’ai mis une chaine de caractères (prefix)). Il suffit de recopier le code server dans un fichier server.js et le code client dans un fichier client.js. Le client envois toute les secondes un nombre aléatoire précédé du ‘prefix’ et le serveur récupère et affiche tout ce qui arrive sur le port 5000 et qui commence par le ‘prefix’

Un peu de poo pour bien appuyer la ou ça fait mal et surtout pour avoir un programme flexible et bien structuré. Transformons ce récepteur udp en un objet qui va générer des évènements.
la notification "use strict" est une règle de bonne pratique qui impose que toutes les variables soit bien déclarées et évite la confusion avec des mots réservés. D'habitude, je ne la mettais pas forcement dans mes exemples, mais je vous conseille vivement de le faire au début de tous vos ficher js.

MyServer et l’espace de nom (namespace) qui va contenir mes objets serveurs et UDP est un objet. L’espace de nom permet de lever toutes ambiguïté avec d’autres objets qui aurrait des noms identiques. Ici, je vais faire référence à un objet MyServer.UDP , ainsi, meme si une autre ressource possède un objet UDP, il ni aura pas de confusion.

Dans cet objet, j’ai défini un socket udp ipv4 (srv), une variable qui contient le ‘prefix’ (qui pour rappel va permettre de filtrer ce qui arrivera sur le port udp), une variable pour savoir si le socket est ouvert ou pas (open) et une variable d’évènement (srvEvents).
Ensuite, j’ai mis 4 instruction srv.on. error , close, listening et message. Pas besoin d’inventer quoi que soit, tout ça est écrit dans la doc de dgram et ce sont 4 signatures d’évènements retournés par le socket. A chaque levé d’un de ces évènements, j’ai dit à mon objet de générer ses propres évènements que j’ai scindé en 2 signatures : ‘server’ pour tout ce qui est informatif sur l’état du socket (error,open et close) et ‘data’ pour l’arrivé de donnée.

Jusque-là, tout est privé et rien n’est accessible en dehors de l’objet. Pour accéder à ce don je vais avoir besoin depuis mon programme, j’ai créé 2 fonctions public (this) pour pouvoir ouvrir et fermer le socket et une pour exposé srvEvent afin de pouvoir m’abonné aux évènements de l’objet .

La dernière ligne 'module.exports' permet d'exporter mon espace de nom pour qu'il soit accessible par d'autres fichiers du programme.

le paramètre (err) dans srv.on("listening", (err) … peut etre supprimé srv.on("listening", () .... C'est juste le residu d'un copié/coller de fénéant et il n'a rien a faire la

Voyons donc maintenant comment utiliser ce merveilleux objet depuis un programme principal.
Je créé mon fichier de programme (le l’ai appelée index.js) et je fais l’import de mon namespace MyServer en chargeant le fichier server.js (./ sous-entend bien évidement qu’il est dans le meme répertoire et je n'ais pas besoin de mettre l'extension .js).

Ensuite je crée une instance de mon objet UDP en lui passant en paramètre le préfix comme je l’ai prévue dans le constructeur de l’objet.

Je l’ouvre (toutes les interfaces port 5000).
Et j’ecris 2 fonctions qui vont recevoir les évènements de l’objet.

Tout ce qui est signé ‘server’, je l’affiche dans la console. Pour ce qui est 'data', j’attends du client un nombre compris entre 1000 et 5000. Comme l’idée de départ c’était ‘comment traiter des données, je vais appliquer un petit traitement à ce que je reçois. Pour l’exemple, je découpe le nombre que je reçois en 2. Une division par 1000 pour une donnée et le modulo 1000 pour l’autre et je place le résultat entier de ces opérations dans un tableau Data []
Voila, je peux continuer d'ecrire le reste de mon programme. Mon tableau Data sera mis a jour a chaque fois que l'objet enverra des données, sans aucune incidence sur le reste

C’est là que l’on arrive au point le plus important qui caractérise vraiment NodeJs.

Si j’avais écrit ça avec un autre langage en utilisant des threads, je serais obligé de verrouiller Data[] pour accéder à ses valeurs. Ça voudrait dire placer un verrou pour que le serveur UDP ne modifie pas Data[] au moment où je vais avoir besoin d’y accéder. Avec NodeJs, pas besoin. Comme il est mono thread, il est tout simplement impossible qu’il y ait en meme temps une écriture et une lecture des données. Ça, c’est fondamental. J’ai écrit des dizaines (centaines…) de ligne à essayer d’expliquer ça des gens qui n’ont jamais pus comprendre la différence entre ce concept mono thread asynchrone et du multithreading alors que tout tient là-dedans. Si je veux maintenant utiliser mes données Data[], il me suffit de le faire le plus simplement du monde.

Exemple, je veux afficher Data[] toutes les 1.3 seconde (donc complétement désynchronisé avec la réception puisque le client les envois toutes les secondes). J’ajoute donc dans mon programme une simple fonction avec timer qui va le faire : Je peux modifier la valeur 1000 du client comme bon me semble, ça ne changera absolument rien et toutes les 1.3 seconde mon programme affichera la valeur à l’instant de Data[] sans aucune incidence sur la réception UDP

Voila, en quelques ligne seulement, on a un serveur udp totalement asynchrone qui est capable recevoir et de mettre à jour des données en les transférants par des évènements et ces données sont disponible à n’importe quel instant pour le reste du programme sans aucune notification vers le serveur.

Pour le projet de redscreen qui veut asservir des verins en fonction de valeurs arrivant sur un port udp et des données arrivant sur un port série, techniquement, ça devient très simple. Il suffit de créer un nouvel objet dans l’espace de nom MyServer (qui s’appellerait par exemple SERIAL : ) Cet objet ouvrirait le port série et transférerait les données entrantes via un évènement exactement de la meme façon qu’avec l’udp. Il suffirait ensuite d’ecrire la procédure d’asservissement des vérins dans la fonction timer du programme principale (ou pourquoi pas, de passer Data à un objet VERINS : qui gèrerait l’asservissement).

Un petit zip avec tout ça. J’ai chiadé un peut plus le code pour pouvoir utiliser le même objet aussi bien en tant que client qu’en tant que serveur et une option qui montre comment le serveur peut répondre au client si besoin.
appclient.js et appserver.js peuvent être lancés chacun dans une console. En image, ça donne ça :

Et le zip

Avec MSG, on s'était amusé avec les résistances dans la rubrique ‘python’. J’avais écrit mon premier exemple en C# et j’avais dit que le transcrirait en python. Sauf que par erreur, j’avais dans un premier temps fait la transcription en javascript pour nodejs, du coup j’avais réécrit ensuite en python. Comme le code js existe et que je ne l’avais pas effacé, je vous le donne. Vous entrez la valeur d'une résistance et ca vous retourne les couleurs

Je viens de voir que le tuto avait dépassé les 50000 .
Objectif 100000

Je n’avais jamais évoqué l’usage des ports série avec NodeJS mais comme j’ai suggérer a redscreen de le faire, je m’assure que cela fonctionne. L’idée, c’était d’ajouter un objet ‘COM’ au namespace MyServer de façon à ce qu’il soit vu exactement de la meme façon que l’objet 'UDP' par le programme principal.
J’ai pour ça utiliser le npm serialport (npm install serialport).

L’objet est créé dans le namspace MyServer à la suite de l’objet UDP (notez bien la virgule qui sépare les 2 objet !). Il expose les mêmes fonctions, à savoir Open, Close et 2 signatures d’évènement pour différencier les données des infos serveur. Le constructeur attend 2 paramètres, le nom du port com et la vitesse.

Coté programme principale, j'ai juste a instancié un objet COM (srvcom) en lui passant en paramètre le nom du port série et la vitesse puis ajouter les 2 évènements exactement comme pour l'udp. Pour l'exemple, j'envois depuis un terminal série une chaine de caractères "Hello Da World" (avec un fin de ligne) que le programme reçoit et il la range dans le tableau COMData en splittant sur les espaces.