programmer un mini shell!

Salut tout le monde.

je suis pas un as de la programmation, et en ce moment je suis sur un projet consistant a realiser un mini shell;

J'ai code mon mini shell, les commandes fonctionne parfaitement, et maintenennt je suis a la phase des builtins et signaux. Pour les builtins, je pense pouvoir les recoder, mais pour les signaux, je suis un peu bloque la.

En fait le man de signal ne m'aide pas beaucoup, je dois gerer les signaux comme dans le shell par defaut du system(je suis sous linux). j'aimerais donc que vous me donniez des astuces pour programmer la gestion des signaux, je ne suis pas autorise a utiliser des fonctions comme fflush(stdout), juste la commande signal dans mon code.

Je peux arriver a coder mes fonctions pour les signaux si vous m'edifiez un avec des astuces pratiques.

merci infiniment pour votre precieuse aide.

A bientot.

Tu veux faire quoi exactement avec les signaux ? Un shell ne fait rien de particulier avec les signaux. A part si tu essaies de coder le built-in "trap" ?

Salut!

Je m'exprime peut etre mal.

En fait je veux que les signaux soient gerer dans mon shelle comme dans le shell par defaut. Si par exemple j'entre Ctrl+C au clavier, mon invite de commande doit se rafficher et non celle du shell par defaut Si j'appuie la touche de rappel d'une commande(fleches montantes et descendante du clavier) je dois revoir les commandes comme dans mon tcsh et dans mon bash. Des trucs des ce genre

je veux juste gerer un peu les signaux afin d'optimiser mon mini shell. L'idee que j'ai est par exemple de definir une fonction qui recupere le signal(handle_signal par exemple), et qui sera rappeler dans elle meme. Je ne sais pas si elle me pemettra de bien controler les signaux, et si oui , je voudrais un bout de code a titre d'exemple et un peu explique, qui me permettra de commencer, car j'arrive pas a bien scerner l'utilisation des signaux et je suis dans les delais pour rendre mon projet
Voila, maintenant si j'ai utilise peut etre les termes a tort, j'espere que ma problematique est plus precise
Merci de me donner une petite piste..

merci pour votre attention

Comment lances-tu ton shell actuellement ? Si tu le fais depuis un autre shell, il y a des chances pour que ce soit celui-ci qui intercepte les caractères spéciaux en premier.

Citation:

---

Envoyé par sympaval

En fait le man de signal ne m'aide pas beaucoup, je dois gerer les signaux comme dans le shell par defaut du system(je suis sous linux).

---

Salut

Le principe d'un signal/kill est le suivant
Tu codes une fonction destinée à être exécutée à réception d'un signal. Cette fonction peut faire ce que tu veux mais tu n'as pas le droit de la mettre autre chose que void et avec un paramètre de type int. Ce paramètre recevra le signal reçu
Exemple

Code:

---

1 2 3 4

void myFunc(int sig) { ... blablabla... }

---

Ensuite, tu dois armer ton code pour qu'il soit redirigé sur la fonction dès qu'il reçoit un signal x. Ca se fait une seule fois par la fonction signal. Mais rien ne t'empêche de relier ta fonction à plusieurs signaux

Code:

---

1 2 3

signal(10, myFunc); signal(11, myFunc); signal(12, myFunc);

---

Ainsi, si ton programme reçoit un signal 10, 11 ou 12 (envoyé depuis l'extérieur via kill) il sera automatiquement redirigé sur myFunc puis, une fois myFunc terminée, reprendra son travail normal.

Ensuite ben c'est tout à l'exception d'un tout petit détail: sur un Unix de base, quand la fonction est appelée à réception d'un signal X, la procédure est alors désarmée. Et ensuite si le pgm reçoit de nouveau un signal X, il se comporte alors par défaut.
Pour palier à ce pb, on a l'habitude, dans la fonction, de programmer un réarmement automatique
Exemple

Code:

---

1 2 3 4 5

void myFunc(int sig) { signal(sig, myFunc); ... blablabla... }

---

Ainsi quand le pgm reçoit un signal X il est redirigé sur myFunc pendant que le mécanisme de détournement est désarmé. Puis la fonction commence son exécution et réarme alors elle-même le mécanisme.

Ce comportement de désarmement automatique n'est pas présent sous Linux. Si une fonction est armée, elle reste armée jusqu'à ce qu'on la désarme manuellement.

salut :)
c'est trés interessant comme sujet et je vous conseille aussi d'inclure une connexion à votre shell c'est à dire le modéle client/serveur en utilisant les sokets :ccool:

Merci infiniment pour ta reponse.

Pour la question sur la facon de lancer mon shell, je lance pour le moment comme un programme a partir de mon shell par defaut.

j'ai bien note tes orientations, juste une question. comment je peut assigner la variable "int sig" pour eviter le "warning : unsused parrameter sig) lors de la compilation?

je peut lui donner juste n'importe quelle valeur et ca n'aura pas d'influence sur le comportement de ma fonction "myFunc"?

merci encore.

Citation:

---

Envoyé par sympaval

j'ai bien note tes orientations, juste une question. comment je peut assigner la variable "int sig" pour eviter le "warning : unsused parrameter sig) lors de la compilation?

je peut lui donner juste n'importe quelle valeur et ca n'aura pas d'influence sur le comportement de ma fonction "myFunc"?

---

Amusant. Effectivement, la variable "int sig" est impérative car elle sert à stocker le signal reçu. Mais si tu ne l'utilises pas, alors elle devient inutile et perçue comme telle par le compilo.

A mon avis, la meilleure chose à faire est de mettre la ligne de réarmement "signal(sig, myFunc)" en début de code de myFunc(). Même si ça ne sert pas sous Linux, ça rend ton programme portable sur Unix où elle est nécessaire et ça a l'avantage d'utiliser la variable donc plus de warning à la compilation...

Bonsoir

Regardes la fonction ioctl. Elle permet de parametrer certaines options de ton terminal. Entre autres tu peux désactiver les signaux et récuperer les l'entrée sans que celle-ci soit bufferisée (ICANON), tres pratique pour gérer les touches fléchées.

Merci pour vos reponses!

J'ai pu gerer au moins le Ctrl + C, qui ne tue pas le processus fils(mon mini shell). mais deja ma fonction "handle_signal" marche bien, et ainsi je vais essayer de prgresser en essayant plusieurs choses. Surtout a pres ce ce minishell1, je dois realiser un minishell2, ou je dois cette fois gerer encore plusieurs options(les touches flechees, tabulations, et bien d'autres que je connais pas encore). Donc la j'aurai plus besoin de votre experience en prog.

Toutefois j'ai une autre preoccupation dont je prie de ne pas m'en tenir rigueur si je commets une erreur de poser le probleme ici plutot que d'ouvrir une nouvelle discussion.

En fait je dois programmer un client et serveur de communication. Le serveur doit etre lance en premier et affiche son PID apres le lancement. Le client prend comme parametres le PID du serveur et une chaine de caracteres. Le client doit communiquer au serveur la chaine passee en parametre et le serveur doit l'afficher. Bien que je dois gérer les valeurs de retour d'appel systèmes, les fonctions perror() et strerror() ne sont pas autorisées sur ce projet(Mais j'ai l'habitude gerer et d'afficher mes messages d'erreur sans utiliser ces focntions, donc c'est pas tres important ce details, juste qu'il fait partie du sujet).
comme details pour la gestion du projet,

La communication entre le client et le serveur doit se faire uniquement a l'aide des signaux. Le serveur doit afficher la chaine rapidement : 15 secs pour 100 chars c'est trop long. Il faut traiter plusieurs clients a la suite. J'ai droit a une variable globale par programme (a justifier). je n'ai le droit qu'aux signaux SIGUSR1 et SIGUSR2.
Options:
Gestion des erreurs de transmission et reemission. Gestion de conflits entre clients simultanes. Gestion correcte des ressources (temps d'utilisation CPU...)

Voila c'est un peu ca le sujet. Il ne s'agit de developper une appli client/serveur, mais d'ecrire deux programmes qui fonctioneront en client et en serveur comme explique plus haut, le language de programmation etant le C et les programmes seront compiles sous UNIX.

Merci emcore pour votre attention.

J'ai du faire un minitalk, l'idée est d'utiliser le bit à bit pour envoyer les informations, une foi qu'elle est reçue, tu renvois un signale pour dire que tu peux en envoyer une nouvelle, ainsi de suite.

Bonne chance.

Oui transmission bit à bit avec SIGUSR1 pour un 0 et SIGUSR2 pour un 1. Ton handler enregistré par sigaction() reçoit en paramètre un singinfo_t qui contient entre autre le PID du process qui a émis le signal, donc avec ça tu peux gérer plusieurs clients.

Le plus délicat ça sera de définir ton protocole de communication.

Salut!

merci pour ta reponse, mais si tu pouvais etre un lus explicite. En fait je sais bien mipuler le binaire, mais comment est ce aue je dois traiter exactement l'information a envoyer, et les envoies simultanes?

Merci d'etre un peu plus claire et si possible un petit algo, ne serait ce qu'en language humain.

Désolé, je ne sais plus exactement comment faire, je me rappel juste avec quoi j'ai fais ça :/
Mais normalement avec la direction dans laquelle nous t'orientons, tu devrais trouver tout ce qu'il te faut pour terminer ton projet :)

De mémoire, tu décomposes le message envoyé en char. Tu envois chaque char bit par bit de l'autre côté tu recompose le char, une foi que le char est bien réceptionné tu réceptionnes le suivant ou alors la transmission est terminée car tu as transmis tous les char du message.
Pour envoyer les différents bit, il faut utiliser SIGUSR1 et SIGUSR2 pour 0 et 1 comme l'a dit matafan.

Je me rappel que j'avais du placer un usleep(pas trop elevé) de manière intelligente. Mais comme je n'ai pas accès à mon travail pour le moment, je ne peux pas aider plus :/ Mais ça n'est pas un mal, avec tout ça tu devrais trouver si tu cherches bien :ccool:

En fait on ne peut pas vraiment utiliser kill() pour envoyer le signal, parce qu'avec kill() le signal envoyé est perdu si le process cible bloque le signal (ce qui sera le cas si le server est déjà dans le signal handler).

Par contre on peut utiliser sigqueue() à la place de kill(), qui ne perd pas de signal : si le signal et bloqué dans le process cible alors le signal est mis en queue, et le process cible le verra quand il démasquera le signal (i.e. quand il sortira de son signal handler).

Et il se trouve que sigqueue(), en plus du signal, permet d'envoyer un int de donnée en plus du signal (c'est le 3ème argument). Donc on peut en profiter pour envoyer un caractère d'un coup (ou même 4 d'ailleurs) plutôt que d'envoyer chaque caractère bit par bit.

Cette optimisation mise à part, la logique est la suivante :

Dans le client :

- Pour chaque char de la chaine à envoyer
..- Pour chaque bit du char
....- Utiliser sigqueue() pour envoyer un SIGUSR1 ou SIGUSR2 suivant qu'on veut envoyer un 0 ou un 1

Dans le serveur, on utilisera une structure de données globale (par exemple une liste chainée) qui permettra d'enregistrer, pour chaque client, les données reçues jusqu'à présent. Les éléments de cette structure permettront de "se souvenir" d'où on en est entre deux appels du handler, et devront forcément contenir :

- Le pid du client
- La chaine de caractères contenant les données reçues
- A quel char on en est dans cette chaine
- A quel bit on en est dans ce char

Il n'y a pas de problème d'accès concurrents sur ces données, puisque les signaux USR1 et USR2 seront masqués quand le handler est appelé.

Ensuite la logique est la suivante :

- Installer le signal handler pour SIGUSR1 et SIGUSR2 (mettre SA_SIGINFO dans sa_flags, et mettre SIGUSR1 et SIGUSR2 dans le sa_mask)
- Boucler indéfiniment ( for ( ; ; ) sleep(1); )
- Dans le signal handler
..- Récupérer les données pour le pid concerné
..- Ajouter le bit reçus dans les données du pid concerné

Pour signaler la fin des données, on pourra par exemple envoyer un caractère nul ('\0'), que le signal handler devra détecter.

Citation:

---

Envoyé par Sve@r

Bah non, quand-même pas. Bien que super intéressant comme sujet (je me suis amusé une fois à coder un Morse avec trait/point remplacés par SIGUSR1/SIGUSR2), ce n'est pas le but de son TP quoi.

---

Si justement ça m'en a tout l'air, puisque "La communication entre le client et le serveur doit se faire uniquement a l'aide des signaux". Et je ne vois pas en quoi les signaux seraient utiles si on utilisait des sockets.

Citation:

---

Envoyé par matafan

Si justement ça m'en a tout l'air, puisque "La communication entre le client et le serveur doit se faire uniquement a l'aide des signaux". Et je ne vois pas en quoi les signaux seraient utiles si on utilisait des sockets.

---

Oups t'as raison. J'avais pas vu la partie "par signaux". J'ai donc supprimé mon post erroné...

Citation:

---

Envoyé par sympaval

Merci d'etre un peu plus claire et si possible un petit algo, ne serait ce qu'en language humain.

---

Ben un truc de ce type: tu dois envoyer "bonjour". Le caractère "b" se code 0x62 donc 01100010. Le caractère "o" se code 0x6F donc 01101111. Le caractère "n" se code 01101110 etc etc.
Donc t'envoies 01100010 01101111 01101110 en codant "0" par SIGUSR1 et "1" par SIGUSR2 en rafale de kill. En utilisant la technique de Matafan de mise en file d'attente pour éviter d'en perdre de l'autre coté...

Citation:

---

Envoyé par matafan

Dans le serveur, on utilisera une structure de données globale (par exemple une liste chainée) qui permettra d'enregistrer, pour chaque client, les données reçues jusqu'à présent. Les éléments de cette structure permettront de "se souvenir" d'où on en est entre deux appels ...

---

Je me demande comment le serveur va pouvoir faire la différence entre "SIGUSR reçu de client1" et "SIGUSR reçu de client2" dans le cas où les 2 clients sont lancés en parallèle...

Citation:

---

Envoyé par matafan

Et il se trouve que sigqueue(), en plus du signal, permet d'envoyer un int de donnée en plus du signal (c'est le 3ème argument). Donc on peut en profiter pour envoyer un caractère d'un coup (ou même 4 d'ailleurs) plutôt que d'envoyer chaque caractère bit par bit.

---

Ou alors utiliser cet int pour faire passer le pid du client...

Salut les gars!

J'ai pas pu tomber sur vos precieux messages jusqu'a cet instant.

Et je constate que vos dernieres suggestions sont vraiment enrichissantes. La logique des listes chainees convient aussi bien pour moi, et j'aimerais a la suite de ce message que Matafan me dise si j'ai compris le principe comme il l'attendais.
En fait voici comment je vois le truc.
Je cree une structure domaine a la maniere indiquee par Matafan, et je code une petite fonction dont le but sera de remplir ma structure a chaque appel.
Les elements ont entres en fin de liste, pour ainsi gerer l'ordre d'arriver des messages pour l'affichage. Ainsi Quand le serveur recois un signal, il emplit la chaine correspondant au PID concerne, et si le PID n'est pas celui de l'element en cours, il cree une nouvelle structure et l'insere en tete de liste, il fait ainsi pour tous les clients dont il recois les signaux, et apres il affiche la liste element par element.

J'espere que c'est bien comme cela que ca finctionne, si non merci de repreciser ce qui n'a pa ete bien compris.

J'ai quand meme quelques autres questions: En fait pour remplir ma structure je dois la malloc, et je dois la malloc le char * qui continedra les donnees recues car la chaine de caractaire n'est pas passee en dur au serveur ( les messages sont envoyes char par char et bit par bit). De ce fait comment connaitre la taille dont je dois malloc ce champ? Puisque jusqu'ici ma solution etais de coder le message cote client et l'envoyer char par char, bit par bit, puis cote serveur de decoder le message et afficher les char au fur et mesure qu'il en recoit.
Aussi pour le projet nous n'avons droit qu'a certains appels systeme dont sigqueue ne fait pas partie; du coup la gestion de plusieurs clients simultanes devient impossible avec le seul kill.

J'aimerais aussi bien comprendre cette expression qu'a utliser matafan :
Installer le signal handler pour SIGUSR1 et SIGUSR2 (mettre SA_SIGINFO dans sa_flags, et mettre SIGUSR1 et SIGUSR2 dans le sa_mask)
- Boucler indéfiniment ( for ( ; ; ) sleep(1); )
- Dans le signal handler
..- Récupérer les données pour le pid concerné
..- Ajouter le bit reçus dans les données du pid concerné
Que veut dire exactement "installer signal handler pour SIGUSR1 et SIGUSR2 (mettre SA_SIGINFO dans sa_flags, et mettre SIGUSR1 et SIGUSR2 dans le sa_mask)" ?

Merci

Pour connaitre la taille à malloc, tu peux strlen la chaine de base que tu veux transmettre. Avant de la transmettre, tu envoi la longueur de la chaine que tu auras transformé (int => char*) bit par bit aussi.

Je crois que ça peut marcher comme ça aussi.

Ouais Zouc!

Mais juste que ca va faire trop de "kill" (32 pour envoyer le PID, 32 pour envoyer la longueur de la chaine, et ensuite la chaine de caractere bit par bit). De plus vue que j'qi pqs le droit a sigqueu, je ne vois comment gerer plusieurs cleintys en meme temps, car le serveur ne saura toujrs pas de qui vient le signal, a moins d'envoyer le pid autant de fois qu'il faut envoyer de signal. Ce qui devient trs lourd.

Pour le moment je vais deja essayerde bien gerer un seul client, et j'espere que j'qurqi l'qstuce pour gerer plusieurs client avec kill d'ici la.

Mais j'aimerais toujours bien comprendre l'expression :"Installer le signal handler pour SIGUSR1 et SIGUSR2 (mettre SA_SIGINFO dans sa_flags, et mettre SIGUSR1 et SIGUSR2 dans le sa_mask)" qui figure dqns les mqn et que j'qi retrouvee ici, sans pouvoir la decortiquer.

Merci encore et a bientot.

Je vais essayer de regarder, si j'ai le temps, comment j'ai fais dans mon minitalk et je te tiens au courant demain je pense.

EDIT :

Le nombre de kill change quoi ?

Merci les gars !

je m'excuse vraimnt pour ma derniere question sur l'installation du handler et autres. Vous savez ce n'est pas evident de faire de gros projets avec peu d'experience. mais j'ai encore lu et relu le man de sigaction, et je commence a vior un peu ce que me recommande matafan, meme si je nme vois pas encore trop comment implementer cela avec kill.
Au depart comme je dis j'ai voulu afficher les caracteres au fur et a mesure de leur reception, mais la il fallait gerer la vitesse.

Autre chose, avec sigaction proposer par matafan, il n'ya que les signaux POSIX.1b et SIGCHLD qui remplissent les camp PID et sender ID du process de la structure siginfo_t, mais pas SIGUSR1 et SIGUSR2 d'apres ce aue j'ai lu. Du coup dans le cadre de mon projet sigaction devient equivalent a signal, mis a part sa portabilite.
J'aimerais donc dans la mesure du possible que mqtqfn me rassure de toutes les possibilites de sigaction pour les signaux SIGUSR1 et SIGUSR2.

J'ai essaye d'utiliser une technique telle que:
Avant d'envoyer le mesage, chaque client envoie d'abord son PID code sur 32 bits (donc 32 signaux). Et cote serveur, lorsqu'il recoit 32 signaux il renvoie le PID a tous les process du groupe, et chacun evaluera pour etre sur que le serveur a bien reu son PID, ce aui fera office de ok, avant de commencer a envoyer les signaux correcpondants aux messages.

Mais du coup, puique je ne sais comment sont definis les handlers dans les autres process du groupe, c'est un risque, j'en ai pour preuve, j'ai envoye un SIGUSR1 a mon firefox et ceci a courcicuite tout mon systeme. J'ai ete oblige de d'enlever mon disque dur et le remonter pour qi'il recommence a fonctionner.

Vous voyez donc que la gestion des communications simultanees reste problematique avec les elements qui me sont fournis/autorises. Mais si on nous a demande cela c'est que c'est bien possible, maisntenent c'est comment le faire avec les appels systeme autorises qui reste un mistere.

Donc pour remplir la structure definie plus haut, je serai bloque car je ne connaitrai que le PID d'un seul client a la fois, et je ne saurai jamis qui q reellement envoye un ZERO ou un UN. Sigaction comme j'ai dit ne peut pas me fournir les infos sur le PID avec SIGUSR1 et SIGUSR2.
Je cherche encore l'astuce pour pouvoir remplir me structure avec les PID adequats, et en utilisant (et sigaction).

Merci encore les gars.

sigaction peut tout à fait manipuler SIGUSR1 et SIGUSR2. Pour tout dire j'ai codé un truc qui fait ce que tu veux, avec kill et sigaction, et ça marche à peu près à part quelques détails sans grande importance sur le principe. Donc, tu peux le faire ;)

Puisque tu ne peux utiliser que kill(), c'est un peu plus compliqué. Il faut savoir que quand un process reçoit un signal envoyé par un kill() et que ce signal est bloqué (parce qu'on est déjà dans le handler de ce signal par exemple), le signal est "mis en attente", et il sera "pris en compte" quand ce signal sera démasqué (par exemple quand on sortira du signal handler). Donc très bien me diras tu, on ne perd aucun signal, il n'y a pas à s'embêter. En fait si. Parce si deux signaux du même type sont envoyés par le même process pendant que ce signal est bloqué, alors un seul signal est mis en queue. Donc pas de chance, si tu as deux 0 ou deux 1 consécutifs à envoyer, tu peux en perdre un des deux.

La solution et d'instaurer un dialogue entre le client et le serveur. Après chaque bit reçu, le serveur enverra un signal au client pour lui indiquer qu'il est sorti de son handler et que le client peut poursuivre la transmission. Donc en gros :

Dans le client :
- Pour chaque bit
-- Envoie du signal
-- Mise en attente d'un signal (pause())

Dans la boucle principale du serveur :
- S'il y un client dans la liste globale des clients, envoie d'un signal au client
- Mise en attente d'un signal

Dans le signal handler du server :
- Recherche du client dans la liste globale des clients
- Si le client n'est pas trouvé, création d'une nouvelle entrée
- Ajout du bit dans les donnée du client
- Si on vient de recevoir le dernier bit à 0 d'un char à 0, signalant la fin d'un transfer
-- Affichage du message
-- Suppression du client de la liste des clients

Quelques éléments pour t'aider :

Pour enregister un handler pour USR1 et USR2 avec sigaction :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

struct sigaction sa; sigset_t sset;   sigemptyset(&sset); sigaddset(&sset, SIGUSR1); sigaddset(&sset, SIGUSR2);   sa.sa_sigaction = sighandler; sa.sa_mask = sset; sa.sa_flags = SA_SIGINFO;   if ( sigaction(SIGUSR1, &sa, NULL) || sigaction(SIGUSR2, &sa, NULL) ) { perror("sigaction"); return 1; }

---

Dans le hander tu peux récupérer le pid comme ceci :

Code:

---

1 2 3 4 5

void sighandler(int s, siginfo_t *si, void *ctx) { fprintf(stderr, "Sig %d from %d\n", s, si->si_pid); }

---

Merci Matafan, tu es vraiment genereux.

Mais pour que tu penses pas que je suis paresseux ou laxiste, voici les seules fonctions et appels systemes auauels j'ai droit.

Fonctions Autorisees : malloc, free, pause, sleep, usleep, exit
Appels système autorisés: signal, kill, getpid, sigaction

Tu vois un peu pourquoi quand on part sur la base des fonctions avancees, ca me complique un peu la tache, car je sais j'y ai pas droit et que si je les utilise, j'ai une note negative pour mon projet.

Merci toutefois pour tous tes efforts, on finira par faire marcher le truc.

Merci encore

Tu n'as besoin d'aucune autres fonctions (ah si, une fonction d'affichage dans le genre puts(), sinon tu vas avoir du mal à afficher les messages). sigemptyset() et sigaddset() sont des macros, pas des fonctions, donc pas de problème pour les utiliser.

Si j'ai cherché un peu c'est parce que ça me semble intéressant comme sujet. D'ailleurs ça m'a permis d'apprendre quelques subtilités sur les signaux que je ne connaissais pas.

Citation:

---

Envoyé par matafan

La solution et d'instaurer un dialogue entre le client et le serveur. Après chaque bit reçu, le serveur enverra un signal au client pour lui indiquer qu'il est sorti de son handler et que le client peut poursuivre la transmission.

---

Ouch, hyper long non ???

Citation:

---

Envoyé par matafan

Si j'ai cherché un peu c'est parce que ça me semble intéressant comme sujet.

---

Ouais moi aussi ça me plait. J'ai même envie de me le faire de mon coté...

Cool!

Ouais pour afficher les messages, j'ai pas de souci. j'ai ma fonction my_putstr qui le fait, donc pas de sopuci a ce niveau.

je reste encore un peu bloque juste q deux niveaux:

- Tu me confirme bien bien que je peux utiliser siginfo_t avec USR1 et USR2, et recuperer le PID du sender (Meme avec les derniers details que je t'ai donnes)?

-On garde toujours notre logique d'utilisation de liste chainees?

- Je n'arrive toujours pas a cerner comment passer les deux derniers parametres de sigactions. L'usage ne me parait pas aussi proche que ca de celui de signal

C'est sur ce dernier point que j'essaye de m'attarder pour le moment. Quand j'aurai bien compris comment mnipuler sigaction, je pourrai alors peaufiner mon projet.

Ta technique d'utilisation des listes chainees me semble tres bonne, je pense que mon seul souci est comment recuperer le PID car je nai pas encore une assez bonne maitrise de sigaction. Et ma methode consistant a faire du pimpon entre le client et le serveur en evoyant a chaque fois le PID du client n'est pas optimal, car des fois le massage n'est pas bien affiche.

Si tu m'ajoute encore quelques lignes simples ca pourra toujours m'aider car je suis pas sur de sortir aussitot des documents sur sigaction dans le delai qui m'est imparti.

Aussi, aurai-t-tu un mot sur la gestion de la vitesse et de des ressources (temps d'utilisation CPU...)?

Je vais me mettre encore a fond dessus.

Merci.

S'il te plait Matafan,

Tu peux me dire a quoi correspond ton parametre ctx dans ton exmple de sighandler?

Merci.

Oui, sigaction fonctionne bien avec USR1 et USR2, et on peut récupérer le pid dans le champs si_pid du siginfo_t passé au handler.

La liste chainée, c'est vraiment la solution la plus simple à coder, mais pas la plus efficace si tu as beaucoup de client puisqu'il faut à chaque fois parcourir toute la liste à la recherche du client qu'on est en train de traiter. Une solution plus scalable serait d'utiliser un hash. Mais bon c'est du détail, l'intérêt de l'exercice n'est pas là.

Pour ce qui est de la taille des messages, tu as deux solutions : soit le client commence par envoyer la taille du message à suivre, ce qui permet au serveur d'allouer d'un coup un buffer suffisant, soit tu indiques la fin de la chaine par un charactère spécial (par exemple '\0'). Dans ce cas le serveur devra être capable de commencer avec un buffer d'une taille par défaut, à agrandir si besoin au fur et à mesure que les données reçues débordent. Tu peux soit l'agrandir en gérant une liste de buffers, soit faire un realloc.

Le troisième argument du handler (ctx dans mon exemple) est en fait un pointeur vers une structure ucontext_t, qui est le contexte du thread qui a lancé le signal (stack, registres...) et ne doit pas être utilisé (setcontext a désormais un comportement indéfini dans un signal handler). Il est là pour des raison historiques.

Question performances, je pense qu'on ne peut pas éviter le dialogue continu, à chaque bit, entre le client et le serveur. D'une manière générale il faut essayer de limiter au maximum le temps passé dans le signal handler.

Un autre point qui a une grande influence sur le comportement du programme est le choix du client que tu vas choisir de signaler à la sortie du signal handler du serveur. Si tu choisis toujours le même client (e.g. le premier dans ta liste), alors seul celui-ci pourra dialoguer avec le serveur. Le deuxième client devra attendre que le premier ait envoyé sont message intégralement avant de pouvoir envoyer son deuxième bit. Si au contraire tu signal un client différent à chaque fois, alors tous les clients progresseront à la même cadence, bit par bit. Au final le temps sera toujours le même pour que tous les clients envoient tous leurs bits, mais suivant la solution retenue ce temps sera occupé différemment.

Enfin d'une manière générale il faut bien garder à l'esprit qu'un signal handler est appelé de manière asynchrone. Il faut donc bien faire attention à ce qu'aucune des données manipulées dans le handler ne soit modifiées (en dehors du handler) avec les interruption non masquées. Sinon le handler pourrait être appelé à un instant où ces données sont dans un état inconsistant.

Merci Matafan!

Tu peux être sur que j'avance là, je compte te donner les résultats ce jour.

Et pour les macros sigaddset et sigemptyset permettant de remplir et vider les signaux, comment est-ce qu'elles fonctionnent réellement? Quelle est vraiment leur place dans notre algo? Je veux dire au moment on y fait appel comme l'exemple ci-dessus, quelle est l'action visée pour le programme?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Pour enregister un handler pour USR1 et USR2 avec sigaction : struct sigaction sa; sigset_t sset;   sigemptyset(&sset); sigaddset(&sset, SIGUSR1); sigaddset(&sset, SIGUSR2);   sa.sa_sigaction = sighandler; sa.sa_mask = sset; sa.sa_flags = SA_SIGINFO;   if ( sigaction(SIGUSR1, &sa, NULL) || sigaction(SIGUSR2, &sa, NULL) ) { perror("sigaction"); return 1; }

---

Code:

---

1 2 3 4 5 6

Dans le hander tu peux récupérer le pid comme ceci : void sighandler(int s, siginfo_t *si, void *ctx) { fprintf(stderr, "Sig %d from %d\n", s, si->si_pid); }

---

Et de plus je n'ai besoin de les utiliser aue pour le handler du serveur non? Puisque pour le client la réception d'un signal signifie simplement que le serveur l'écoute. Je pense que pour le client je peux d'ailleurs utiliser un simple "signal", mais bon ce n'est vraiment pas un souci. Donne moi juste un peu de détail sur l'usage pratique des macro sigaddset, sigemptyset stp.

Merci à toi et à vous tous.

Le champ sa_mask du struct sigaction qui est passé à sigaction() sert à définir quels signaux doivent être masqués lorsqu'on est dans le signal handler. Les macros sigemptyset() et sigaddset() servent initialiser ce champs à la valeur désirée (c'est en fait un champs de bits, chaque bit correspondant à un signal, et ces macros permettent de setter les bits désirés).

Par défaut, le signal qui a déclenché l'appel du handler est masqué. Pour nous ce n'est pas suffisant, car on a deux signaux différents qui peuvent déclencher l'appel du handler. Si on est appelés pour USR1 in faut aussi masquer USR2, et si on est appelés pour USR2 il faut aussi masquer USR1. On indique donc à sigaction() de systématiquement masquer USR1 et USR2 quand le handler est appelé.

Effectivement tu peux te contenter de signal() dans le client. Le handler ne peut être appelé que pour un signal, donc on n'a pas besoin de masquer un autre signal. Cela dit il vaut toujours mieux utiliser sigaction() car signal() n'est pas très portable.

Ah tiens d'ailleurs sous linux ce sont bien des fonctions, pas des macros. Mais je vois mal comment on pourrait s'en passer si tu n'as pas droit non plus à sigprocmask().

Salut matafan!

je viens de decouvrir une autre chose par un de nos assistants concernant les signaux.

En effet, il se pourrait que sur certains systeme comme freeBSD par exemple, certaines fonctions specifiques ne doivent pas etre appelees dans un signal handler.

En occurence la fonction malloc ou toute fonction faisant appel a malloc dans un handler, ou encore manipuler des structures dynamiques. En effet sous Unix ca va marcher, mais sous d'autre systeme ca va segfaulter.

Du coup je suis un peu confus quant a la methode de remplissage de ma structure dans le handler.

Je t'envoie ce lien:

http://www.openbsd.org/cgi-bin/man.c...86&format=html

A bientot,.

Si tu n'as pas de malloc() ou de free() (ou autres fonctions du même genre) en dehors de ton signal handler, alors il n'y a pas de problème. Si tu en as, alors tu as deux solutions :

- Toujours masquer les signaux pour appeler ces fonctions en dehors de ton signal handler (sigprocmask())

- Ou bien, allouer les structures à l'avance en dehors du signal handler, et les utiliser les structures pré-allouées dans le signal handler. Si tu fais ça alors il faut protéger l'accès aux structures avec un sémaphore.

Ce genre de problème se rencontre partout, pas que sur BSD. C'est un exemple de ce que je disais quand je disais de ne jamais modifier, en dehors du signal handler, de structures utilisées dans le signal handler. Ici c'est un peu vicieux car les structures en questions sont les structures de contrôle utilisées en interne par la libc pour gérer les allocations mémoire.

Salut matafan!

J'ai termine le projet depuis vendredi(en fait le code).

mais ad je lance le client et le serveur, le serveur boucle sans jamais afficher les messages, et quand le client termine l'envoie de la chaine de caractere et se ferme, le serveur affiche le massage "No such process que j'ai programme", preuve que le serveur envoie bien des signaux au process courant et qu'il a detecte que le process etait arrete.

J'ai essaye de debugger avec gdb, mais c pas evident car a certains moment dans le deboggeur il y a un SIGTRAP, mais j'ai quand meme remarque un truc comme si ma structure n'etais jamais malloccee, car l'errue se produit toujors au niveau du malloc.

Or je ne fais appel a mon malloc que dans le handler et nul part ailleurs.

Je pars sur methode qui me permettra au moins de rende mon projet (Je vais gerer les clients tour a tour, et n'entrer en communication avec un client que lorsque la communication avec le client courrant est terminee, pendant de temps le nouveau clients attends un certains temps et renvoie le bit qui n'a pas ete recu. C'est vrai que ce sera lent au niveau de la vitesse, mais je pourrai gerer plusieurs cleints) mais j'aimerais bien savoir ou j'ai faut pour la methode avec une liste chainee globale, car cette methode me paraissait vraiment pratique.

Si de ton cote tu reussi a implementer la communication avec cettes methode de liste chainee, je te prie de me faire parvenir le code pour que je comprenne ou moi j'ai faut.

Je te tiendrai informe du fonctionnement de la deuxieme methode dans le detail ce soir.

Merci encore pour ton attention.

Salut !

Comme je l'ai dit dans mon precedent message, je veux ici donner la methode que j'ai utiliser pour la communication entre mon client et mon serveur:

Le serveur possede une table d'etat dans laquelle se trouve le pid du client pour la communication en cours.
Lorsque le serveur est en comunication avec un client et qu'il recoit un autre signal, il envoie un signal, il verifie dans la table d'etat pour voir si le pid du client qui a emis le signal corrrespond ou si la table est a zero. si la table n'est pas a zero et que le pid du client ne correcpond pas, un signal est envoye a ce dernier pour lui demander de patienter un moment et de reinitialiser la communication, si le pid correspond ca veut dire que c'est une communication en cours, et donc elle continue, si la table est zero alors le pid du nouveau client est enregistre et une nouvelle communication est initiee.
Je gere egalement les delai d'attente depasse cote client, mais avant ce ferme la connexion avec un client , le serveur lui envoie d'abord un signal pour voir s'il est en vie et que ce n'est pas le serveur qui est attendu, dans ce cas le client reprends l'envoie ou il s'etait arrete. Si le client est arrete, le serveur ferme cette session et attends d'autre clients (En affichant un message "connexion time out")..

Voila c'est un peu lent pour de tres gros teste (Quand on remplit le terminel de caracteres), mais ca marche bien, et je ne perd pas de signal.

Ce fut un plaisir d'echanger a ce sujet ca m'a fait decouvrir plein de chose.

Merci encore a vous tous.

A tres bientot pour d'autres sujets.