Prog C Linux : socket ou Sémaphore ou Pipe ou... Que choisir ?? Besoins d'avis et de conseils Version 2
1 réponse
projlin
En fait, j'explique mal, enfin j'ai du mal à expliquer mon problème.
J'éssaie a nouveau !
Le Père est le seul à avoir accès aux ressources d'un hardware.
Ce hardware peut accueillir jusqu'à 60 clients différents.
Ce hardware, de toutes façons, a 60 segments de mémoire partagée
différents.
Donc, ces segments seront utilisés pour les commandes et le retour de
commandes.
Les clients, donc maximum 60, sont des processus différents et
indépendants.
Ils sont numérotés de 1 à 60 !! (Comme les mémoires partagées)
Ces clients font quelques traitements, mais ils passent leur temps à
dormir,
car en fait, grosso modo, le programme fait 1 seconde de traitement,
envoi une demande au serveur (pour faire bosser le hardware), et là,
par un mécanisme que je n'ai pas encore trouvé, il se met à dormir
(sans prendre de CPU) (merci)
jusqu'à ce que le père lui dise « ok » ou « error » pour cette
demande.
Je corse, car parfois, le client crée un fils, se met en attende de la
mort du fils, et c'est le fils qui fait pareil.
Donc un troisième processus va avoir besoin de faire la même chose
mais à la place du précédant.
Donc, le serveur dialogue avec un client, à un moment, le client crée
un fils, le client ne fait plus rien et c'est le fils qui va dialoguer
avec le serveur
*****************************************************************
(Je fais un aparté pour ne pas passer pour un fou)
Pour le système du client qui fait un fork() pour se mettre en sommeil
et
faire bosser un fils.
On peut avoir besoin de modifier le programme (programme C) de
certaine fonction du client.
Mais on ne peut pas arrêter le hardware, ni les clients pour les
recompiler.
Donc, le client a un mécanisme pour certaine commande, ou plutôt
qu'appeler une fonction interne, il lit un fichier, récupère le nom
d'un exécutable et le lance en fork() exec() et attend sa mort.
C'est un peu comme si ce programme externe au client était une
fonction interne du client, mais avec ce mécanisme, on peut les
recompiler en pleine action !!! Sans tout arrêter.
*****************************************************************
Exemple physique :
Donc, imaginons que le serveur (PID 800) discute tranquillement avec
un client
(PID 801) (801 n'est pas forcément un fils de 800)
Donc, le processus 800 et 801 dialogue entre eux (juste un dialogue de
synchro puisque de toutes les façons, les données sont au chaud dans
la mémoire partagée)
A un moment, 801 décide de créer un fils (PID 802).
et là 802 dialogue avec 800 comme au début 800 et 801 (Mais 801 ne
fait plus rien, il attend la mort de 802)
Quand 802 a fini il fait un exit() et hop, 801 reprend son activité.
Là, je pense que c'est clair comme explication avec mes numéro de PID
non ???? ;-)
Les seules choses dont j'ai besoin en dialogue entre processus, sont
les suivantes.
1] Le serveur PID 800 est en sommeil. (sans prendre de CPU)
1] je ne sais pas comment ? pipe, sémaphore ou magie noire ou je ne
sais pas quoi)
1] C'est le but de mon SOS comment ???
2] Le client PID 801 charge la mémoire partagée
2] Réveille le serveur (PID 800) je ne sais pas comment ? Forcement
je sais pas comment l'endormir ;-)
2] il lui donne son numéro de client (entre 1 et 60), imaginons
CLIENT 13 (ça porte bonheur)
2] Se met en sommeil pour attendre que le serveur ait fini cette
commande.
3] Le serveur PID 800 est réveillé par l'étape 2. Il reçoit CLIENT
13
3] il lit la mémoire partagée du client 13
3] il exécute la commande sur le hardware
3] 10 secondes plus tard, quand la commande est finie, 800 réveille
le client 801 pour lui dire ok
C'est tout sauf que le serveur peut être réveillé par plusieurs
clients et le client peut laisser sa place à son fils pendant quelques
secondes ou minutes.
voilà là j'ai tout expliquer le plus clairement possible.
alors queues pipe socket ou je sais pas quoi ??
le client a pas de donnée a recevoir du serveur puisque seul le
serveur lui parle, et le serveur a besoins de savoir qui lui parle
pour identifier le numéro du client de 1 à 60...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
mordicus
wrote:
***************************************************************** (Je fais un aparté pour ne pas passer pour un fou) Pour le système du client qui fait un fork() pour se mettre en sommeil et faire bosser un fils.
On peut avoir besoin de modifier le programme (programme C) de certaine fonction du client. Mais on ne peut pas arrêter le hardware, ni les clients pour les recompiler.
Pourquoi ne pas cree des .so ? tu peux les charger dynamiquement. Un systeme de plug-ins quoi ... c'est quand meme vachement plus simple !
Exemple physique : Donc, imaginons que le serveur (PID 800) discute tranquillement avec un client (PID 801) (801 n'est pas forcément un fils de 800) Donc, le processus 800 et 801 dialogue entre eux (juste un dialogue de synchro puisque de toutes les façons, les données sont au chaud dans la mémoire partagée) A un moment, 801 décide de créer un fils (PID 802). et là 802 dialogue avec 800 comme au début 800 et 801 (Mais 801 ne fait plus rien, il attend la mort de 802) Quand 802 a fini il fait un exit() et hop, 801 reprend son activité.
Là, je pense que c'est clair comme explication avec mes numéro de PID non ???? ;-)
Les seules choses dont j'ai besoin en dialogue entre processus, sont les suivantes.
1] Le serveur PID 800 est en sommeil. (sans prendre de CPU)
man 3 sleep ou man msgrcv
1] je ne sais pas comment ? pipe, sémaphore ou magie noire ou je ne sais pas quoi) 1] C'est le but de mon SOS comment ???
2] Le client PID 801 charge la mémoire partagée 2] Réveille le serveur (PID 800) je ne sais pas comment ? Forcement je sais pas comment l'endormir ;-)
man signal ou msgsnd
2] il lui donne son numéro de client (entre 1 et 60), imaginons CLIENT 13 (ça porte bonheur) 2] Se met en sommeil pour attendre que le serveur ait fini cette commande.
man msgsnd
3] Le serveur PID 800 est réveillé par l'étape 2. Il reçoit CLIENT 13 3] il lit la mémoire partagée du client 13 3] il exécute la commande sur le hardware 3] 10 secondes plus tard, quand la commande est finie, 800 réveille le client 801 pour lui dire ok
man signal ou msgsnd
J'ai ecris quelques petits examples d'ipc, envois moi un mail si ca t'interesse !
a+
ProjLIN@hotmail.com wrote:
*****************************************************************
(Je fais un aparté pour ne pas passer pour un fou)
Pour le système du client qui fait un fork() pour se mettre en sommeil
et
faire bosser un fils.
On peut avoir besoin de modifier le programme (programme C) de
certaine fonction du client.
Mais on ne peut pas arrêter le hardware, ni les clients pour les
recompiler.
Pourquoi ne pas cree des .so ? tu peux les charger dynamiquement.
Un systeme de plug-ins quoi ... c'est quand meme vachement plus simple !
Exemple physique :
Donc, imaginons que le serveur (PID 800) discute tranquillement avec
un client
(PID 801) (801 n'est pas forcément un fils de 800)
Donc, le processus 800 et 801 dialogue entre eux (juste un dialogue de
synchro puisque de toutes les façons, les données sont au chaud dans
la mémoire partagée)
A un moment, 801 décide de créer un fils (PID 802).
et là 802 dialogue avec 800 comme au début 800 et 801 (Mais 801 ne
fait plus rien, il attend la mort de 802)
Quand 802 a fini il fait un exit() et hop, 801 reprend son activité.
Là, je pense que c'est clair comme explication avec mes numéro de PID
non ???? ;-)
Les seules choses dont j'ai besoin en dialogue entre processus, sont
les suivantes.
1] Le serveur PID 800 est en sommeil. (sans prendre de CPU)
man 3 sleep
ou
man msgrcv
1] je ne sais pas comment ? pipe, sémaphore ou magie noire ou je ne
sais pas quoi)
1] C'est le but de mon SOS comment ???
2] Le client PID 801 charge la mémoire partagée
2] Réveille le serveur (PID 800) je ne sais pas comment ? Forcement
je sais pas comment l'endormir ;-)
man signal
ou
msgsnd
2] il lui donne son numéro de client (entre 1 et 60), imaginons
CLIENT 13 (ça porte bonheur)
2] Se met en sommeil pour attendre que le serveur ait fini cette
commande.
man msgsnd
3] Le serveur PID 800 est réveillé par l'étape 2. Il reçoit CLIENT
13
3] il lit la mémoire partagée du client 13
3] il exécute la commande sur le hardware
3] 10 secondes plus tard, quand la commande est finie, 800 réveille
le client 801 pour lui dire ok
man signal
ou
msgsnd
J'ai ecris quelques petits examples d'ipc, envois moi un mail si ca
t'interesse !
***************************************************************** (Je fais un aparté pour ne pas passer pour un fou) Pour le système du client qui fait un fork() pour se mettre en sommeil et faire bosser un fils.
On peut avoir besoin de modifier le programme (programme C) de certaine fonction du client. Mais on ne peut pas arrêter le hardware, ni les clients pour les recompiler.
Pourquoi ne pas cree des .so ? tu peux les charger dynamiquement. Un systeme de plug-ins quoi ... c'est quand meme vachement plus simple !
Exemple physique : Donc, imaginons que le serveur (PID 800) discute tranquillement avec un client (PID 801) (801 n'est pas forcément un fils de 800) Donc, le processus 800 et 801 dialogue entre eux (juste un dialogue de synchro puisque de toutes les façons, les données sont au chaud dans la mémoire partagée) A un moment, 801 décide de créer un fils (PID 802). et là 802 dialogue avec 800 comme au début 800 et 801 (Mais 801 ne fait plus rien, il attend la mort de 802) Quand 802 a fini il fait un exit() et hop, 801 reprend son activité.
Là, je pense que c'est clair comme explication avec mes numéro de PID non ???? ;-)
Les seules choses dont j'ai besoin en dialogue entre processus, sont les suivantes.
1] Le serveur PID 800 est en sommeil. (sans prendre de CPU)
man 3 sleep ou man msgrcv
1] je ne sais pas comment ? pipe, sémaphore ou magie noire ou je ne sais pas quoi) 1] C'est le but de mon SOS comment ???
2] Le client PID 801 charge la mémoire partagée 2] Réveille le serveur (PID 800) je ne sais pas comment ? Forcement je sais pas comment l'endormir ;-)
man signal ou msgsnd
2] il lui donne son numéro de client (entre 1 et 60), imaginons CLIENT 13 (ça porte bonheur) 2] Se met en sommeil pour attendre que le serveur ait fini cette commande.
man msgsnd
3] Le serveur PID 800 est réveillé par l'étape 2. Il reçoit CLIENT 13 3] il lit la mémoire partagée du client 13 3] il exécute la commande sur le hardware 3] 10 secondes plus tard, quand la commande est finie, 800 réveille le client 801 pour lui dire ok
man signal ou msgsnd
J'ai ecris quelques petits examples d'ipc, envois moi un mail si ca t'interesse !
