Comment faire communiquer deux programme entre eux en C ?

**Ekinoks** · 11/11/2007, 15h33

Salut !

Je ne sais pas si ce poste a ca place ici ou dans le forum programmation Linux, donc j'espaire ne pas m'étre trompé... :^/

Je me pose la question de savoir quel est la meilleur solution pour faire communiquer deux applications entre elle de manière la plus rapide possible en C sous Linux ? et si la rapidité est beaucoup réduite par rapport a un programme communiquant avec lui même ?

Bon... comme un exemple vaut mieux qu'un long discourt en voici un :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// programmeQuiRecoi
void main()
{
    int num;
    int total = 0;
    while(1)
    {
        scanf("%d\n", &num);
        total += num;
        printf("total = %d\n",num);
    }
}

La méthode ici pour communiquer est faite avec un scanf. En utilisant donc un pipe comme ca :

Code :

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

./programmeQuiEmet | ./programmeQuiRecoi

Mais il y a plusieurs problème avec cette technique (du moins comme je l'utilise actuellement avec un pipe) :
1> La communication ne se fait que dans un seul sens.
2> La communication ne se fait pas petit a petit mais seulement lorsque le programme qui émet est terminé.
3> Le programme peu communiquer avec UN seul autre programme.
4> Pour terminer je ne suis pas sur que les performances avec cette technique soit exceptionnel non ?

Donc en fait il faudrais un mode de communication qui se face dans les deux sens un genre de truc comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
void main()
{
    int num;
    int total = 0;
    while(1)
    {
        receptionDUnInt(&num);
        total += num;
        emitionDUnInt(num);
    }
}

Avais vous une idée de quel technique (portable si possible) utiliser pour faire cela ?

Merci pour votre aide.

**Gruik** · 11/11/2007, 15h55

Salut,

Tu peux voir du côté des files nommées (fifo) ou du côté des sockets unix.
L'avantage des sockets unix c'est que yaurait pas grand chose à changer pour en faire une application réseau.

**souviron34** · 11/11/2007, 16h23

et tu peux avoir aussi un fichier intermédiaire, ou bien de la shared memory si tu sais que tu es sur le même système...

**Ekinoks** · 11/11/2007, 17h12

Merci pour vos réponses.

Gruik> OMG ! Ca a l'aire génial les FIFO !!! =) C'est comme ça que marche les drivers Unix non ?
Si non au niveaux performance ? serais tu si c'est aussi performant qu'un appelle a une fonction internet au programme ?
Pour les sockets c'est intéressent si on travaille en réseau mais pour un fonctionnement local, les performances risque d'être médiocre par rapport au FIFO ou a de la "shared memory" non ?

souviron34> Bha un fichier intermédiaire risque de prendre beaucoup de temps, par contre de la "shared memory" ça peu être sympa car très rapide c'est bien ça ?

**Gruik** · 11/11/2007, 17h16

Les fifos ont une existance dans le systeme de fichier, mais je crois que leur contenu est géré en memoire partagée (pas sur disque).
Je crois que les sockets unix sont implementés avec des fifos (en tout cas c'etait le cas avec un kernel 2.4)

**PsychoH13** · 11/11/2007, 17h20

NB : Ça s'appelle des pipes au passage.

**Ekinoks** · 12/11/2007, 12h30

Envoyé par Gruik

Les fifos ont une existance dans le systeme de fichier, mais je crois que leur contenu est géré en memoire partagée (pas sur disque).
Je crois que les sockets unix sont implementés avec des fifos (en tout cas c'etait le cas avec un kernel 2.4)

Cela signifie que l'utilisation de "sockets unix" en local est aussi rapide que les "fifos" qui est aussi rapide que de la "memoire partagée" ?

**Sve@r** · 12/11/2007, 18h27

Envoyé par Ekinoks

Cela signifie que l'utilisation de "sockets unix" en local est aussi rapide que les "fifos" qui est aussi rapide que de la "memoire partagée" ?

Non car le noyau implémente en plus pour les pipes une politique de dualité (tant que le lecteur ne lit pas, l'écrivain est bloqué et inversement) que ne font pas les sockets ni la shm. Donc plus de travail = moins de rapidité...

**Ekinoks** · 12/11/2007, 19h45

Merci pour ta réponse Sve@r.

Envoyé par Sve@r

Non car le noyau implémente en plus pour les pipes une politique de dualité (tant que le lecteur ne lit pas, l'écrivain est bloqué et inversement) que ne font pas les sockets ni la shm. Donc plus de travail = moins de rapidité...

Ha ok... donc en fait, les FIFO se sont des drivers c'est ça ? comme les présente le tuto de Skyrunner (lien) ?

Ou alors il y a des petites différences entre drivers Unix et les FIFO ?

**Sve@r** · 12/11/2007, 22h19

Envoyé par Ekinoks

Ha ok... donc en fait, les FIFO se sont des drivers c'est ça ? Ou alors il y a des petites différences entre drivers Unix et les FIFO ?

Non. Ce n'est pas parce que le noyau Unix implémente une politique particulière pour un fifo qu'un fifo est un driver. Un driver c'est un programme qui prend en charge un périphérique. Un fifo c'est un mécanisme de communication interprocessus pris en charge par le noyau

**gangsoleil** · 13/11/2007, 10h16

Bonjour,

Il existe de très nombreux moyens de communiquer entre deux programmes :

pipes nommés
fichiers
sockets
mémoire partagée
signaux
base de données
files de messages
...

Après, il ne reste plus qu'à savoir ce que tu veux transférer, si ça doit être bidirectionnel ou non, et les performances que tu attends.

Dans ton cas, tu as précisé que tu voulais des performances et une communication bidirectionnelle, mais pas ce que tu souhaite transférer (volume et nombre de différentes valeures)

**Ekinoks** · 13/11/2007, 16h28

Envoyé par Sve@r

Non. Ce n'est pas parce que le noyau Unix implémente une politique particulière pour un fifo qu'un fifo est un driver. Un driver c'est un programme qui prend en charge un périphérique. Un fifo c'est un mécanisme de communication interprocessus pris en charge par le noyau

Ha ok, je comprend mieux...

Envoyé par gangsoleil

Dans ton cas, tu as précisé que tu voulais des performances et une communication bidirectionnelle, mais pas ce que tu souhaite transférer (volume et nombre de différentes valeures)

Ok... donc en fait je réfléchie à faire une sorte de... "machine graphique virtuelle" :^/
Le principe c'est que les fenêtres graphiques soit géré par une machine virtuelle.
Le but de la chose est de permettre a plusieurs programmes indépendant (programmer avec n'importe quel langage y compris du shell) de travailler facilement sur la même fenêtre graphique.

**souviron34** · 13/11/2007, 17h44

X fait ca tres bien

(XWindow pour ceux qui ne connaissent pas)

**Ekinoks** · 13/11/2007, 18h55

Envoyé par souviron34

X fait ca tres bien

(XWindow pour ceux qui ne connaissent pas)

Ha bon ?? est tu sur ? car j'ai fait des recherches sur Google et j'ai trouvé aucun site qui parlait de ca...

as tu bien compris le programme que je voulais faire ?

Une des implications de ce programme est de pouvoir créé facilement un environnement graphique en shell pour un script shell.
Puis pouvoir ajouter des fonctionnalités à cette application graphique en créant un second programme qui va communiquer directement avec la fenêtre graphique.
Par exemple le second programme peu rajouté juste un bouton qui servira a quitter le programme.

Le but est de pouvoir rajouter des fonctionnalité à l'application graphique sans avoir besoin de se plonger dans les codes sources de l'application mère et sans que celle ci est eu a prévoir cela...

Il faut donc pour faire cela que la "machine graphique virtuelle" puissent communiquer avec les programmes qui dirige l'application graphique de manière bidirectionnelle et rapide.

(j'ai pris l'exemple du shell mais ca peu aussi être du python du C ou autre...).

**souviron34** · 13/11/2007, 19h46

Envoyé par Ekinoks

Le principe c'est que les fenêtres graphiques soit géré par une machine virtuelle.
Le but de la chose est de permettre a plusieurs programmes indépendant (programmer avec n'importe quel langage y compris du shell) de travailler facilement sur la même fenêtre graphique.

Le X serveur fait ca..

Maintenant, en ce qui concerne ceci :

Une des implications de ce programme est de pouvoir créé facilement un environnement graphique en shell pour un script shell.
Puis pouvoir ajouter des fonctionnalités à cette application graphique en créant un second programme qui va communiquer directement avec la fenêtre graphique.
Par exemple le second programme peu rajouté juste un bouton qui servira a quitter le programme.

Le but est de pouvoir rajouter des fonctionnalité à l'application graphique sans avoir besoin de se plonger dans les codes sources de l'application mère et sans que celle ci est eu a prévoir cela...

Il faut donc pour faire cela que la "machine graphique virtuelle" puissent communiquer avec les programmes qui dirige l'application graphique de manière bidirectionnelle et rapide.

eh bien tcl/tk fait tres bien ca...
(base sur X aussi

)

Comment faire communiquer deux programme entre eux en C ?

Linux

Discussions similaires

Partager

Partager