[Résolu]Conseil architecture d'un projet (communication avec un démon)

Laserpithium · Le 13/06/2011, à 12:37

Bonjour,

Je souhaite installer dans mon appartement des LED RGB et piloter depuis mon PC la couleur de ces LED via le port série.
J'ai tout ce qu'il faut pour la partie électronique (entre le port série et les LEDs): un PIC reçoit les infos du port série (luminosité et couleurs) et commande les LED en fonction.

Ma question porte donc sur la partie "PC" du projet. Tel que je vois les choses aujourd'hui, je pense construire cela en 2 parties:
- Un programme qui gère le port série et l'émission de données (paramètrage du port, réception des données de couleur, mise en forme et envoi sur le port). Typiquement, ce programme serait un démon lancé dès le démarrage, et qui attend de recevoir de nouvelles commandes à transmettre via le port série. A réception d'une commande, il vérifie sa validité, mets les données en forme (protocole de communication) et envoie le tout sur le port.
- Un programme/script en espace utilisateur, qui réceptionne les entrées utilisateurs (sur le terminal), vérifie leur validité, et balance le tout au démon émetteur ci-dessus.

Je vois assez bien comment réaliser le démon et l'émission sur le port série, mais là où je patauge c'est pour passer les données au démon.
Idéalement, mon programme en espace utilisateur (rgbcontroler) devrait fonctionner un peu comme apt-get: on lui passe des commandes générales (install, remove etc) et les paramètres correspondants.
Donc par exemple pour allumer les LED en rouge, l'utilisateur tape "rgbcontroler color red" par exemple. rgbcontroler vérifie alors la validité de la commande et envoie au démon l'ordre d'envoyer sur le port série le code couleur 255;0;0.
Cependant, je ne vois pas comment réaliser cette communication. J'ai regardé du côté de DBus, mais cela me semble plus adapté à des programmes fonctionnant en permanence, pas à des appels ponctuels pour envoyer des données.
De plus, il semble que les bonnes pratiques interdisent à un utilisateur de communiquer directement avec un démon.

Quelqu'un pourrait-il me mettre sur la piste pour réaliser ce passage de données au démon?
Pour info, programmes écris en C, et à terme on peut envisager une future GUI en Qt pour rgbcontroler.

PS: je précise que pour simplifier les choses, le démon contrôlant le port série tournera sur une autre machine (serveur perso) que le PC servant d'interface utilisateur. Les 2 machines étant reliées via le réseau local.

Dernière modification par Laserpithium (Le 26/06/2011, à 18:56)

Hibou57 · Le 13/06/2011, à 14:31

Laserpithium a écrit :

Cependant, je ne vois pas comment réaliser cette communication. J'ai regardé du côté de DBus, mais cela me semble plus adapté à des programmes fonctionnant en permanence, pas à des appels ponctuels pour envoyer des données.

Je verrai bien, soit un pipe, ou encore plus universel et souple, un connexion par socket. En même, c’est une réponse un peu automatique de ma part, parce que pour l’IPC, je ne jure que par les sockets.

Il faut juste faire attention au numéro de port, qui doit être au moins 1024, parce que seul root peut ouvrir une socket en écoute sur un numéro de port en dessous.

Il peut être également nécessaire de corriger la configuration de Apache, s’il est présent, afin qu’il n’écoute pas automatiquement sur toutes les interface disponibles. Pour cela, voir le fichier “/etc/apache2/ports.conf”. En prenant soin de vérifier ces deux points, rien ne s’oppose au bon fonctionnement d’une communication par sockets.

-- EDIT --

Laserpithium a écrit :

PS: je précise que pour simplifier les choses, le démon contrôlant le port série tournera sur une autre machine (serveur perso) que le PC servant d'interface utilisateur. Les 2 machines étant reliées via le réseau local.

Alors plus de doute : une connexion par socket.

Dernière modification par Hibou57 (Le 14/06/2011, à 07:34)

Laserpithium · Le 13/06/2011, à 23:16

J'ai pas mal regardé, et effectivement c'est exactement ce qu'il me faut, merci.

2 questions:
- Pour ce type d'application, faut-il mieux utiliser des sockets tcp ou udp ? Je n'ai pas trouvé beaucoup de choses à ce sujet, tous les tuto semblent utiliser uniquement le tcp.
- Si je comprends bien, j'ai la partie serveur qui tourne en permanence (démon), et la partie client qui récupère les entrées utilisateurs et les envoie par socket à la partie serveur. Mais alors, cela signifie que la socket client sera recréée à chaque fois (lorsque l'utilisateur veut envoyer une valeur via l'outil en ligne de commande, la socket est créée, la valeur envoyée, puis la socket détruite et le programme côté client s'arrête). Est-ce la bonne manière de procéder? Ou faut-il aussi un démon sur le PC utilisateur, qui gère la socket d'envoi, et récupère (je vois pas trop comment par contre) les commandes utilisateur avant de les envoyer?

Hibou57 · Le 14/06/2011, à 06:01

Hillou,

Le TCP apparait plus souvent dans les documentations et tutoriels, parce que c’est le plus fréquent en pratique, c’est ce qui est utilisé pour le HTTP et le FTP par exemple.

Le TCP, c’est la connexion flux garanti, et l’UDP, c’est la connexion par paquets dont certains peuvent se perdre (c’est utilisé pour certains streamings multimédias avec lesquels la vitesse est plus important que de ne pas perdre le moindre octet)

Je dirais alors plutôt TCP pour toi. Tu en pense quoi ?

Je repasse un peu plus tard pour compléter.

-- EDIT --
Suite

Laserpithium a écrit :

- Si je comprends bien, j'ai la partie serveur qui tourne en permanence (démon), et la partie client qui récupère les entrées utilisateurs et les envoie par socket à la partie serveur. Mais alors, cela signifie que la socket client sera recréée à chaque fois (lorsque l'utilisateur veut envoyer une valeur via l'outil en ligne de commande, la socket est créée, la valeur envoyée, puis la socket détruite et le programme côté client s'arrête). Est-ce la bonne manière de procéder?

Le principe universel est le suivant (il varie seulement avec l’échelle et quelques autres choses, mais ça reste l’unité de base) : le serveur s’initialise en ouvrant une socket d’écoute sur une adresse et un port, de préférence supérieur ou égale à 1024 dans ton cas. Cette adresse et ce port, constituent l’adresse effective à laquelle le serveur sera contacté (avec HTTP le port par défaut, 80, est implicite, et n’apparait donc pas explicitement dans les adresses, mais ici, tu devra le donner explicitement). Le client du serveur envoie une requête au serveur à cette adresse + port. Le serveur reçois sur la socket d’écoute, une demande de connexion. Il accepte cette demande de connexion, en créant une autre socket. Sur cette autre socket, il reçoit la requête et envoie la réponse, puis ferme la socket (il peut aussi la garder ouverte à la demande du client, mais on va rester simple).

Je reformule d’une autre manière, pour être plus clair : la socket d’écoute, est comme un bouton de sonnette. Et la socket de communication, c’est comme la poignée de main à travers laquelle passe un message. Le bouton de sonnette est là en permanence, mais la poignée de main est refaite à chaque échange.

Tu comprends ?

Laserpithium a écrit :

Ou faut-il aussi un démon sur le PC utilisateur, qui gère la socket d'envoi, et récupère (je vois pas trop comment par contre) les commandes utilisateur avant de les envoyer?

Le client peut être sur une machine, et le serveur sur l’autre machine. Le serveur commandera tes LED, donc il sera sur la machine à laquelle seront connectées les LED. Le client, sera sur la machine à partir de laquelle, toi, tu souhaite commander les LED.

Le client qui enverra les requêtes au serveur, ne sera pas obligé d’être actif en permanence, donc pas obligé d’en faire un daeamon. C’est comme avec un navigateur : le serveur d’un site peut être actif en permanence, mais tu n’ouvre le navigateur que quand tu souhaite aller sur le site. Ici, c’est idem, tu pourrait avoir une application set-led qui tu lancerais depuis la ligne de commande ou avec une GUI, et l’application peut se terminer dés qu’elle a envoyé la commande et reçu confirmation de sa bonne réception.

P.S. j’ai oublié : tu le fais dans quel langage ?

Dernière modification par Hibou57 (Le 14/06/2011, à 07:40)

Laserpithium · Le 14/06/2011, à 10:28

Merci pour ta réponse très claire.
Ce qui me chiffonnait, c'était l'idée de créer et détruire la socket client à chaque appel de la fonction client. Je trouvais plus "propre" de la laisser ouverte en permanence, et d'envoyer des données ponctuellement lorsque l'utilisateur en exprimait le besoin.
Mais si tu me dis que c'est la procédure normale, alors ça m'arrange !

Pour info j'ai pas mal avancé, j'arrive à transmettre des données au serveur qui les reçoit, vérifie leur validité, et transmet une réponse au client "Données reçues OK" ou "Non OK". J'attaque la gestion des erreurs.
Programmation en C, si je fais une interface graphique plus tard ce sera en C++/Qt (KDE power :-) )

Merci de ton aide, ça m'a bien décoincé.

Hibou57 · Le 14/06/2011, à 12:38

Laserpithium a écrit :

Merci pour ta réponse très claire.
Ce qui me chiffonnait, c'était l'idée de créer et détruire la socket client à chaque appel de la fonction client.

Il y en a une qui est ouverte et fermée à chaque requête et une autre qui reste ouverte en permanence. Mais je pense que tu as compris, puisque tu as réalisé des essais qui fonctionnent.

Si tu as besoin d’autres renseignements, ça n’est pas un problème, tant que c’est quelque chose que je connais ça va.

Laserpithium · Le 14/06/2011, à 17:17

Encore une question: d'après ce que j'ai lu, les sockets TCP assurent que le paquet ne sera pas perdu en chemin.
Maintenant, faut-il ajouter lorsque je crée mon paquet de données un bit de checksum afin de s'assurer que le paquet ne sera pas corrompu en chemin (genre bit de parité pour les ports série), ou bien la socket se charge t'elle de cela automatiquement ?

Hibou57 · Le 14/06/2011, à 17:42

Laserpithium a écrit :

Encore une question: d'après ce que j'ai lu, les sockets TCP assurent que le paquet ne sera pas perdu en chemin.
Maintenant, faut-il ajouter lorsque je crée mon paquet de données un bit de checksum afin de s'assurer que le paquet ne sera pas corrompu en chemin (genre bit de parité pour les ports série), ou bien la socket se charge t'elle de cela automatiquement ?

Tu n’as rien de spécial à spécifier, c’est automatique dès que tu choisi le protocole TCP. Ce n’est d’ailleurs pas la socket qui en a la responsabilité (les sockets sont une interface), c’est le protocole TCP lui même et tout seul, qui fait que les paquets ne seront pas perdus, c’est dans ses spécifications. En fait, un paquet peut toujours se perdre sur un réseau (quoique entre deux machines, ça doit être rare), et dans ce cas, le paquet est automatiquement retransmis (sauf avec UDP/IP), et tout cela est transparent pour toi qui est derrière une socket. Pour l’intégrité, c'est Idem, TCP s’en charge déjà. Certains protocoles ajoutent encore un contrôle d’intégrité supplémentaire au dessus, mais pour tes besoins, la fiabilité offerte par TCP sera largement suffisante.

Si ces questions t’intéressent, je peux te poster des bonnes références que j’ai dans mes marques pages (mais ça fait beaucoup de lecture).

Dernière modification par Hibou57 (Le 14/06/2011, à 17:44)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 13/06/2011, à 12:37

[Résolu]Conseil architecture d'un projet (communication avec un démon)

#2 Le 13/06/2011, à 14:31

Re : [Résolu]Conseil architecture d'un projet (communication avec un démon)

#3 Le 13/06/2011, à 23:16

Re : [Résolu]Conseil architecture d'un projet (communication avec un démon)

#4 Le 14/06/2011, à 06:01

Re : [Résolu]Conseil architecture d'un projet (communication avec un démon)

#5 Le 14/06/2011, à 10:28

Re : [Résolu]Conseil architecture d'un projet (communication avec un démon)

#6 Le 14/06/2011, à 12:38

Re : [Résolu]Conseil architecture d'un projet (communication avec un démon)

#7 Le 14/06/2011, à 17:17

Re : [Résolu]Conseil architecture d'un projet (communication avec un démon)

#8 Le 14/06/2011, à 17:42

Re : [Résolu]Conseil architecture d'un projet (communication avec un démon)

Pied de page des forums