mon realloc perso

**Emmanuel Delahaye** · 31/10/2006, 10h55

Envoyé par gdpasmini

Ce que je fais, c'est que je regarde periodiquement la socket pour voir si j'ai un paquet. La socket est non blocante.

Si j'ai un paquet, je parse, sinon, je sors de la fonction...

Etant donné que je ne peux pas utiliser les threads,

Mais si. Même si tu n'as pas accès aux threads, l'application elle même (main() etc.) est un processus, donc un thread.

C'est à elle de boucler avec un select() pour savoir si il y a quelque chose à prendre sur le socket. Il n'y a aucune interruption à mettre en oeuvre au niveau applicatif (de toutes façon, ce serait une absurdité) laisse ça au système, c'est son travail.

**gdpasmini** · 31/10/2006, 11h00

d'ac je vais tenter de modifier ca.

Je ne peux pas utiliser le select sur mon system.. il ne fonctionne pas. Je fais dc un recvfrom non blocant...

Est ce bien ou pas du tout ?

**Emmanuel Delahaye** · 31/10/2006, 11h32

Envoyé par gdpasmini

Je ne peux pas utiliser le select sur mon system.. il ne fonctionne pas.

EDIT: select() ne fonctionne pas, curieux, mais admettons (il faudrait quand même approfondir). Et poll(), ça fonctionne ?

Je fais dc un recvfrom non blocant...

Est ce bien ou pas du tout ?

dc ?

C'est moyen, mais si il n'y a pas d'autres moyens. Tu peux au moins mettre une suspension (sleep(), usleep() ou équivallent), histoire de laisser respirer le processeur...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
   for (;;)
   {
      int n = recvfrom(...);
 
      if (n > 0)
      {
         /* on se reveille, y'a du boulot ! */
      }
      else
      {
         usleep (1000); /* 1 ms */
      }
   }

**gdpasmini** · 31/10/2006, 12h15

En fait au depart, je faisais ca :

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
17
18
19
 
  fdmax = MAX(appel->RTPComm.data_sock, appel->RTPComm.ctrl_sock) + 1;
 
  FD_ZERO(&fds);
  FD_SET(appel->RTPComm.data_sock, &fds);
  FD_SET(appel->RTPComm.ctrl_sock, &fds);
 
 
timeout = 0;	
 
  tv.tv_sec = (time_t) floor(timeout);
  tv.tv_usec = (time_t) ((timeout - floor(timeout)) * 1.0e6);
 
  if (select(fdmax, &fds, NULL, NULL, &tv) < 0) {
    printf("*** connection_listen : select", 1);
  }
 
  if (FD_ISSET(appel->RTPComm.data_sock, &fds)) {
fprintf(stderr, "paquet à lire !\n");

résultat, je ne récupérais que un paquet sur 2... Jai dabord pensé que cela venait de FD_ISSET mais non.. Et si je l'enlevais, ca plantait.. Résultat, j'ai fais un recvfrom non blocant.

Ce recvfrom aussi est dans un timer cette fois ci car j'ai besoin de récupérer des paquets a interval régulier... Je ne pouvais pas tout mettre dans le main()

**Emmanuel Delahaye** · 31/10/2006, 12h25

Envoyé par gdpasmini

résultat, je ne récupérais que un paquet sur 2..

Pourquoi tu mets un timer ? Laisse faire la nature :

Dans ton main() :

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
17
18
19
20
21
22
23
24
25
 
<...>
{
   <...>
 
   fdmax = MAX (appel->RTPComm.data_sock, appel->RTPComm.ctrl_sock) + 1;
 
   for (;;)
   {
      FD_ZERO (&fds);
      FD_SET (appel->RTPComm.data_sock, &fds);
      FD_SET (appel->RTPComm.ctrl_sock, &fds);
 
      if (select (fdmax, &fds, NULL, NULL, NULL) < 0)
      {
         printf ("*** connection_listen : select\n");
      }
 
      if (FD_ISSET (appel->RTPComm.data_sock, &fds))
      {
         fprintf (stderr, "incoming data !\n");
      }
   }
   <...>
}

**gdpasmini** · 31/10/2006, 12h28

oki, je vais tenter ca... mais disons que le main est deja bien rempli !!!

Ce qui me fait peur c'est qu'il ne chope plus tout les paquets comme ca le faisait avant...

Est ce que je dois toujours faire une socket non blocante ?

D'autre part, tu penses que ca pourrait expliquer les bugs ?

**Emmanuel Delahaye** · 31/10/2006, 12h37

Envoyé par gdpasmini

oki, je vais tenter ca... mais disons que le main est deja bien rempli !!!

Je parle d'architecture. Par main(), j'entends 'le processus principal' (et thread unique, puisque tu n'a pas le droit aux threads).

Il ne peut y avoir qu'une boucle avec select(). Si tu dois faire autre chose, il faut revoir l'architecture de main(). (mais select() prend aussi les évènements de stdin...)

Ce qui me fait peur c'est qu'il ne chope plus tout les paquets comme ca le faisait avant...

Tu verras bien. Il faut vivre dangereusement. Mais je ne vois pas pourquoi il raterait quoique ce soit, à moins que le système et/ou les drivers aient été écrits par des bras cassés...

D'autre part, tu penses que ca pourrait expliquer les bugs ?

recv() dans une interruption ? Je n'ose même pas imaginer ce que ça peut faire...

En définitives, tu as surtout un gros problème d'architecture logicielle, c'est à dire de conception. Problème récurrent, c'est la partie la plus difficile de l'informatique et elle n'est pas ou peu enseignée...

**gdpasmini** · 31/10/2006, 12h59

et oui.. j'imagine que ca doit te faire mal aux oreilles d'entendre tout ce que je te dis ! Je n'ai pas eu le plaisir de participer moi meme a l'architecture du programme. J'ai juste récupéré le bébé et, avec ma faible experience, j'ai continué ce qui avait été commencé !

recv() dans une interruption ? Je n'ose même pas imaginer ce que ça peut faire...

Tout ce que tu n'as jamais osé imaginé, je le fais pour toi !!

Moi j'ai au moin deux socket.. et chacune d'entre elle doivent recevoir des paquets. L'une des sockets dois recevoir les paquets périodiquement...

Dois je tout mettre dans le thread principale ?

Dans ce cas, je dois faire la manip avec le select citée plus haut deux fois de suite a chaque passage dans la boucle infinie de mon main ?

De plus, les socket doivent elles etre non blocante ?

D'autre part je ne comprends pas :

Il ne peut y avoir qu'une boucle avec select(). Si tu dois faire autre chose, il faut revoir l'architecture de main(). (mais select() prend aussi les évènements de stdin...)

**Emmanuel Delahaye** · 31/10/2006, 13h47

Envoyé par gdpasmini

Je n'ai pas eu le plaisir de participer moi meme a l'architecture du programme. J'ai juste récupéré le bébé et, avec ma faible experience, j'ai continué ce qui avait été commencé !

Alors il faut demander des explications aux prédécesseurs, ou, si l'architecture n'est pas bonne (on va resté calme et poli...), il faut la revoir...

Moi j'ai au moin deux socket.. et chacune d'entre elle doivent recevoir des paquets. L'une des sockets dois recevoir les paquets périodiquement...

Dois je tout mettre dans le thread principale ?

Oui.

Dans ce cas, je dois faire la manip avec le select citée plus haut deux fois de suite a chaque passage dans la boucle infinie de mon main ?

Non. Une seule boucle, un seul select(). Par contre, après le select(), un traitement par socket surveillé, évidemment. (et même, pour chaque socket, on peut surveiller jusqu'à 3 évènements : réception des données, émission d'une donnée, réception d'une commande hors bande).

Il faut relire d'urgence la doc de select(). C'est ma fonction la plus astucieuse de POSIX.1, mais elle est assez complexe.

select() 'attend' un des évènements programmés. (en fait, il suspend la tâche courante qui est réveillée dès qu'un évènement programmé se produit).

C'est, vu de l'application, le fameux mécanisme de synchronisation dont je te parle depuis le début :

"une interruption génère un évènement qui décoince la tâche en attente".

Ici, on est du coté de la tâche et de l'attente avec select(). L'interruption et l'évènement sont gérés par le driver et le système.

De plus, les socket doivent elles etre non blocante ?

Pas utile avec select(). C'est select() qui attend (qui bloque l'exécution de la tâche).

**gdpasmini** · 31/10/2006, 14h12

Je suis désolé, tu vas me prendre pour un gros lourd (t'aurais peut etre pas tord ;-) ) mais j'ai le sentiment que c'est une tres bonne piste car j'utilise des recvfrom a tout va dans des interuptions ou des timers..

(en fait, il suspend la tâche courante qui est réveillée dès qu'un évènement programmé se produit).

Ce qui me fait peur, c'est que le select suspend le main puisque c'est la tache courante.. or le main dois etre capable de gérer aussi mon interface graphique. dans sa boucle infinie...

Ceci ne pose t'il pas de probleme ?

**Emmanuel Delahaye** · 31/10/2006, 14h26

Envoyé par gdpasmini

Ce qui me fait peur, c'est que le select suspend le main puisque c'est la tache courante.. or le main dois etre capable de gérer aussi mon interface graphique. dans sa boucle infinie...

Ceci ne pose t'il pas de probleme ?

Déjà évoqué :

Envoyé par -ed-

Il ne peut y avoir qu'une boucle avec select(). Si tu dois faire autre chose, il faut revoir l'architecture de main().

Alors dit exactement ce que doit faire ton programme, sinon, on va tourner autour du pot 107 ans...

Et comme tu l'avais évoqué au début, select() est certes bloquant, mais on peut le décoincer régulièrement avec le timer (dernier paramètre : quelques milli-secondes) pour faire autre chose (dans ce cas, on se base sur la valeur retournée par select() pour savoir si c'est une échéance du timer et faire un traitement cyclique).

**gdpasmini** · 02/11/2006, 09h01

Salut ! T'as passé un bon jour férié ??

Bon je crois que je vais préciser mon sujet en effet.. Sinon, on va pas s'en sortir. Enfin, surtout moi ! ;-)

Je fais de la voix sur ip comme tu l'avasi surement remarqué.

Dans mon programme, le main dois faire :

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
17
18
19
20
21
 
main()
{
   //initialisation
   ...
 
   while(1){
 
     écoute_paquet();
 
     //gestion de l'interface graphique
 
     ...
 
     //appui sur un bouton particulier de l'ihm
     envoi_dappel();
 
     //fin de la gestion de l'ihm
     ...
   }
}

Ainsi ecoute_paquet() dois regarder si un appel arrive donc je dois regarder sur une socket particulière (donc utilisation du select non ?)

Ensuite, si je n'ai pas recu de paquets sur cette socket, il faut passer a la gestion de l'ihm. Si je veux lancer un appel, j'utilise la fonction envoi_dappel().

Cette fonction envoi un paquet puis ecoute sur la meme socket que précedement le resultat de l'appel. Si l'appel est lancé, je dois ecouter tout les paquets RTP qui arrive sur une autre socket.

ma fonction doit donc ressembler a ca :

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
 
envoi_dappel()
{
   //appel du poste
   msg_send();
 
   while(1)
   {
     FD_ZERO (&fds);
     FD_SET (so, &fds);
     FD_SET (so, &fds);
 
     if (select (fdmax, &fds, NULL, NULL, NULL) < 0)
     {
	  printf ("*** connection_listen : select\n");
     }
 
     if (FD_ISSET (so, &fds))
     {
	  fprintf (stderr, "incoming data !\n");
	  res = recvfrom(so, (void *)thread_rx_buf, 1000, 0, (struct sockaddr *)&thread_rx_Rx, &thread_rx_Rxlen);
 
          //traitement du paquet, etablissement de l'appel
 
          ...
      }
 
       //appel etabli, ecoute des sockets rtp et rtcp pour la reception des donnees
 
      //ecoute et traitement des donnees
 
      //est ce que je dois utiliser encore une fois le select ??
      recvfrom(socket_rtp);//non blocant
 
      recvfrom(socket_rtcp);//non blocant
 
      //fin de la boucle while, on retourne au debut pour voir si on a recu un signal de fin d'appel sur la premiere socket. Sinon, on retroune ecouter les nouveaux paquets de donnees.
 
      //tant qu'on a pas fini l'appel, on reste dans la boucle while...
    }
...
 
}

Voila c'est beaucoup plus explicite je pense.. Est ce que cette architecture serait stable ?

Le select est il a utiliser deux fois ?

**Emmanuel Delahaye** · 02/11/2006, 10h11

Envoyé par gdpasmini

Je fais de la voix sur ip comme tu l'avasi surement remarqué.

Non. Application réseau, bien sûr, mais pas plus. De toutes façons, peu importe...

Dans mon programme, le main dois faire :
<...>
Voila c'est beaucoup plus explicite je pense.. Est ce que cette architecture serait stable ?

Oui, mais peut être même un peu trop !

Cette application est typique d'une application multi-tâches. Tu ne peux vraiment pas avoir de threads ? Qu'est-ce qui en empêche ? Ton système est certes propriétaire, mais si il est conçu pour des application telecom, il est forcément multi-tâche. Peux-tu me donner une liste des primitives systèmes ?

Nota : Le simple fait que select() soit implémenté signifie probablement que le système à des capacités multi-tâches, car c'est typiquement une fonction de suspension avec déclenchement sur évènements...

**gdpasmini** · 02/11/2006, 10h22

non je ne peux pa faire de mulit_taches... le select a ete modifié comme toutes les autres librairies d'ailleurs pour fonctionner sur ce system.. Je suis désolé mais je ne peux pas vraiment en dire plus.

Le "peut etre meme un peu trop" concerne la stabilité ou la dexcription de l'application ?

Est ce que l'utilisation du select est bonne ou faut il le reutiliser avant les deux autres recvfrom ?

En fait, j'ai tout modifié pour arriver a ca car a la base, tout se passait sosu interuption...

**Emmanuel Delahaye** · 02/11/2006, 10h59

Envoyé par gdpasmini

non je ne peux pa faire de mulit_taches... le select a ete modifié comme toutes les autres librairies d'ailleurs pour fonctionner sur ce system.. Je suis désolé mais je ne peux pas vraiment en dire plus.

Il y a quand même un sérieux problème de conception... Je serais ton chef de projet, j'en dormirais pas la nuit... Il existe des versions embarquées de Linux pour de nombreuses plateformes (y compris PQ2, PQ3 ou Xscale) tout à fait adaptées à ce genre de projet...

On va donc se résigner à travailler à l'ancienne, c'est à dire avec une boucle unique de polling.

Le principe général est le suivant :
(pseudo-code)

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
17
18
19
20
 
main()
{
   init()
 
   for (;;)
   {
      if (evenement_a)
      {
           traitement_a()
      }
 
      if (evenement_b)
      {
           traitement_b()
      }
 
      /* etc. */
   }
}

Les contraintes de conception sont les suivantes ;

les évènements sont des états mis à jours sous interruptions
les traitements sont non blocants.

Dans la pratique, une structure de code

Code :

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

1
2
3
4
5
 
      if (evenement_a)
      {
           traitement_a()
      }

Peut être (pseudo-code) :

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
17
 
{
   timer = quelques ms
   echeance = select (socket_a, socket_b, ..., timer)
 
   if (!echeance)
   {
      if (reception (socket_a)
         recv(socket_a, buffer_a)
 
      if (reception (socket_b)
         recv(socket_b, buffer_b)
 
      if (reception (socket_...)
         recv(socket_..., buffer_...)
   }
}

Ce qui provoque un faible blocage. Mais il me semble que j'avais déjà évoqué cette architecture, non ?

Le "peut etre meme un peu trop" concerne la stabilité ou la dexcription de l'application ?

la stabilité (quand on part dans une boucle annexe, on ne traite plus les autres évènements... blocage plus ou moins temporaire)

**gdpasmini** · 06/11/2006, 16h33

Salut !

ca faisait longtmps ! Je voulais simplement te dire que le probleme venait bien du recvfrom dans l'interruption.. J'ai modifier le select pour pouvoir l'utiliser et totu fonctionne a présent..

Je te remercie infiniement pour ton aide. Tu m'as sauvé la vie !! Enfin presque !

A bientot !

**Emmanuel Delahaye** · 06/11/2006, 16h39

Envoyé par gdpasmini

Je te remercie infiniement pour ton aide. Tu m'as sauvé la vie !! Enfin presque !

J'espère seulement que tu as compris que la conception était plus importante que le codage. Ou plutôt qu'il y a une séquence à respecter dans le développement de tout projet :

"Réfléchir avant d'agir".

**gdpasmini** · 06/11/2006, 16h45

Oui tout a fait, c'est une bonne lecon...

Mais certaine chose ne s'apprenne qu'avec les erreurs.. Ceci est un bon exemple.

D'autre part, je me rend compte également des dangers de faire passer un projet entre des mains différentes.. Le debuggage n'en est que plus compliqué car ce probleme devait exister avant mon arrivé mais ses consequences se sont fait sentir quand j'ai continué le développement..

En tout cas merci encore a toi, je n'aurais jamais découvert mon erreur tout seul !!

J'espere pouvoir te rendre la pareil un jour !!

mon realloc perso

Réseau C

Discussions similaires

Partager

Partager