Discussion :

[manudwarf]

Bonjour,

Afin de m'entrainer à la programmation réseau en C, je voulais réaliser un petit programme serveur sous Linux.

Je cherche de la documentation pour obtenir un résultat similaire à ce que l'on peut trouver habituellement avec les programmes serveurs (je vais prendre l'exemple de MySQL qui représente bien ce que je veux faire).

Pour démarrer/arrêter le démon MySQL, je fais (en root) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/etc/init.d/mysql start|stop

pour effectuer une commande (depuis n'importe quel utilisateur) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql machintruc

Ce qui signifie que j'ai au moins trois exécutables :

• Un premier qui se lance au démarrage, le démon
• Un second qui contrôle le démon (/etc/init.d/mysql)
• Un dernier qui l'interroge (/usr/bin/mysql)

J'ai vu comment fonctionnent les threads, la mémoire partagée, les sémaphores et les files de messages. Mon problème est que je ne sais pas trop comment ordonner tout ça

J'espère avoir été clair... En tous cas je n'ai rien trouvé sur la FAQ et, pour être honnête, je ne sais pas trop quoi chercher...

edit: quand à aller voir le code de MySQL pour comprendre... non, ça ne me tente pas

[ram-0000]

Ce qui signifie que j'ai au moins trois exécutables :

• Un premier qui se lance au démarrage, le démon
• Un second qui contrôle le démon (/etc/init.d/mysql)
• Un dernier qui l'interroge (/usr/bin/mysql)

• Le 1er programme est en fait le démon serveur (qui dans ton exemple s'appelle mysqld). Il y a plein d'exemples sur le net pour écrire un démon qui en plus soit serveur au sens réseau du terme.
• Le 2eme programme est un shell script (qui dans ton exemple s'appelle /etc/init.d/mysqld). Regarde comment sont faits les autres scripts dans le répertoire /etc/init.d et adapte le tien, cela ne devrait pas être trop dur.
• Le 3eme programme est un programme utilisateur qui se comporte en client vis-a-vis du démon serveur TCP/IP. Ce programme est un programme console ou graphique (type Hello World mais un peu plus compliqué) qui se connecte au démon serveur. Les fonctionnalités offertes par ton programme client sont directement dépendantes de ce que sait/veut faire ton démon serveur et le mode de connexion à ce démon serveur est directement dépendant du/des types de connexions acceptées par ton démon serveur.

[manudwarf]

• Le 1er programme est en le démon serveur (qui dans ton exemple s'appelle mysqld). Il y a plein d'exemples sur le net pour écrire un démon qui en plus soit serveur au sens réseau du terme.
• Le 2eme programme est un shell script (qui dans ton exemple s'appelle /etc/init.d/mysqld). Regarde comment sont faits les autres scripts dans le répertoire /etc/init.d et adapte le tien, cela ne devrait pas être trop dur.

Ok, je vais voir ça.

• Le 3eme programme est un programme utilisateur qui se comporte en client vis-a-vis du démon serveur TCP/IP. Ce programme est un programme console ou graphique (type Hello World mais un peu plus compliqué) qui se connecte au démon serveur. Les fonctionnalités offertes par ton programme client sont directement dépendantes de ce que sait/veut faire ton démon serveur et le mode de connexion à ce démon serveur est directement dépendant du/des types de connexions acceptées par ton démon serveur.

Donc pas d'IPC ? Fais suer je me suis grillé plus d'une neurone pour y arriver...

Merci !

[ram-0000]

Donc pas d'IPC ? Fais suer je me suis grillé plus d'une neurone pour y arriver...

IPC veut dire Inter Process Communication. C'est un nom générique qui regroupe toutes les technologies/moyens qui permettent à 2 (ou plus) processus différents de communiquer entres eux en s'affranchissant de la problématique des accès concurrents/simultanés.

Dans ces moyens, on trouve :

• socket
• sémaphore
• signaux
• mémoire partagée
• evenements
• pipe
• ...

Si on reprend ton exemple de MySQL, les moyens IPC mis à disposition par le serveur mysqld pour communiquer avec un ou plusieurs clients sont :

• socket (c'est l'utilité du port TCP 3306)
• pipe
• peut être d'autres encore (je ne connais pas suffisemment les internals de MySQL)

Il faut bien comprendre que c'est le serveur qui dit le ou les moyens qu'il peut utiliser et c'est au client de s'adapter et d'utiliser ceux mis à disposition

[Obsidian]

IPC veut dire Inter Process Communication. C'est un nom générique qui regroupe toutes les technologies/moyens qui permettent à 2 (ou plus) processus différents de communiquer entres eux en s'affranchissant de la problématique des accès concurrents/simultanés.

Même pas forcé : l'utilisation de la mémoire partagée, par exemple, ne garantit pas d'être à l'abri d'accès concurrents. En général, on distingue les I.P.C. en général et les « I.P.C. de SysV » Unix qui englobent mémoire partagée, files de messages et sémaphores, avec une API propre. Les sockets, eux, sont résolument un mécanisme d'IPC, mais c'était la réponse de BSD.

En outre, quand on montre les IPC au sens large, on énumère les procédés qui permettent de faire passer une info d'un processus à l'autre, mais ce n'est pas pour cela que c'est à ça qu'ils servent. L'exemple le plus courant est les signaux Unix : régulièrement, il y a des gens qui essayent de faire du message passing avec. J'avais même un prof, pour qui j'ai beaucoup d'estime par ailleurs, qui comparait cela aux messages de la C.API de Windows, qui balançait ses événements sous forme de LONG. « Vous avez vu ? Sous Unix, on a un seul octet pour envoyer des messages, alors que sous Windows on en a quatre. Ça laisse plus de possibilité ». Je bouillais sur ma chaise. :-)