Discussion :

[zouuc]

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 ?

[nixmind]

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.

[matafan]

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

[matafan]

Quelques éléments pour t'aider :

Pour enregister un handler pour USR1 et USR2 avec sigaction :

Code :

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

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 :

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

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);
}

[nixmind]

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

[matafan]

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.

[Sve@r]

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 ???

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é...

[nixmind]

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.

[nixmind]

S'il te plait Matafan,

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

Merci.

[matafan]

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.

[nixmind]

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 :

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

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 :

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

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.

[matafan]

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.

[matafan]

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().

[nixmind]

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,.

[matafan]

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.

[nixmind]

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.

[nixmind]

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.