Je dois programmer une sorte de "passerelle" (un pc intermediaire sollicite dans les 2 sens de communications).
En gros voila le fonctionnement de la chose :
3 Unites (1, 2, 3) connectees entre elles de la facon suivante :
-1 communique vers 2 via une carte I/O
-2 communique vers 3 via l'ethernet 100Mbits (UDP)
-3 communique vers 2 via l'ethernet 100Mbits (meme cable physique que la comm de 2 vers 3) (TCP)
-2 communique vers 1 via la carte I/O (la meme que la comm de 1 vers 2)
 
1 envoie une masse de donnee. 2 se doit de la traiter puis de l'envoyer direct a 3...TOUT EN RESTANT a l'ecoute de 1. Dans l'autre sens, 3 envoie des donnees a 2. 2 traite les donnes et les envoient a 1...TOUT EN RESTANT a l'ecoute de 3.
 
Vous comprenez que la machine 2 est dc sans cesse sollicitee. Cette "passerelle" recoit des donnees d'une part en provenance de la carte I/O (venant de 1), d'autre part en provenance de l'ethernet (venant de 3) tout en restant a l'ecoute de chacune (1 et 3). Bref tout ca, vous avez compris , ca sent la communication inter-processus : 1 envoie les donnees dans un tube (lecture de la carte I/O), 3 lit la sortie du tube (par ecoute du port ethernet via UDP).De meme dans l'autre sens, 3 envoie des donnees (par remplissage du tube via TCP) et 2 lit la sortie puis ecrit les donnes sur la carte I/O.
 
But primordiale : vitesse maximale du reseau
J'ai choisi UDP de 2 vers 3 car connexion non necessairement securisee or, 3 vers 2 doit etre securise (d'ou TCP).
Je sais qu'il existe plusieurs methode de comm inter-processus, je pensais au "pipe", est ce le meilleur choix ?
 
PS : c du C++ sous W98 avec VC++6

quel OS?
sous GNU/Linux, il y a des 'named pipes' mais
pas besoin de pipe, deux threads (a et b) sur le 2:
a ecoute(read bloquant) la carte et envoi(write non-bloquant) tout à 3 en UDP (ou TCP, car en UDP peut y avoir des pertes de datagrammes ou des datagrammes qui se doublent, etc.)
b ecoute(read bloquant) le 3 (socket) et envoi le tout sur la carte I/O (write non-bloquant)
 
Donc pas de pipes ...

C du VC++6 sous win98.
Hum mouai, les threads (je connais sans plus et jviens de jeter un oeil) ont l'air pas mal ... c koi l'avantage par rapport au pipe ?

Ben justement de pas avoir à te faire chier pour communiquer vu que chaque thread a accès à l'espace mémoire des autres.

 
OK, merci bien  

Peut on acceder a la zone memoire d'un thread ? Si oui, comment ?
 
En fait j'aurais un thread qui executera la fonction de lecture de la carte I/O. Dans cette fonction, il y a un buffer qui stockera les donnees lues sur la carte I/O.
Un autre thread executera une autre fonction qui se contentera de faire des calculs a partir des donnees lues sur la I/O card. Donc il faudra que ce thread puisse acceder a la variable buffer de l'autre thread.
En fait j'aurai 5 threads en execution sur la machine 2. 1 pour chaque fonction (lecture de la carte I/O, calculs etablis sur la machine, envoie par UDP, recois par TCP, ecriture sur la carte I/O)

Declarer ton buffer static
 
EDIT: par contre, il faut mettre en place des mutex

 
Tu veux que ce soit une variable globale alors ? (pour que chaque fonction la voit)

et en plus il me faut tous ca dans l'ordre ; cad qu'il ne faut pas faire des calculs AVT d'avoir lu dans le buffer les nouvelles donnees qui viennent d'arrivee

Ben c'est le but du mutex.
Le lecteur fait :
WaitForSignleObject( hMutex, 0 );
et il restera bloqué à cet endroit tant que le rédacteur n'aura pas déverouiller le Mutex. Cherche de la doc sur la accès concurrent et le problème lecteur / redacteur.

 
 
C ce que je suis en train de faire   ... c du partage de ressources en simultanee en fait. Les semaphores ne feraient pas ? (1 vers 2 puis 2 vers 3 puis 3 vers 2 puis 2 vers 1)...c un passage de jetons non ?
Cependant a la fin de la "boucle" (de 2 vers 1) je ne pourrais pas recevoir les donnees de la carte I/O. Ceci dit le tps de faire une "boucle" est peut etre insignifiant non (ce qui revient a du quasi simultanne)?

En fait, pour la "1ere boucle", je dois utiliser un systeme de jeton : chaque thread commencera apres que son thread anterieur ait commence. Mais a partir du moment ou un thread a commencer, il ne doit plus s'arreter

Un Mutex c'est un verrou => semaphore initialisé à 1, sémaphore "binaire" ou "booléen".

 
Voui merci   je vais utilisez les mutex. deux fonctions consecutives qui fonctionneront de la fonction suivante :
la fonction precedente libere le mutex, la fonction suivante peut alors s'executer. Les fonctions s'enchaineront sans pb, et tout se fera simultanement c bon  

 
-fonction 1 : ecriture dans le buffer
-fonction 2: lecture du buffer - puis mis a jour du buffer
-fonction 3: lecture du buffer
-fonction 4: lecture du buffer (les donnees recues par TCP seront stockees dans ce buffer)
-fonction 5: ecriture dans le buffer (pour envoyer a l'io card)
 
Problemes :
 
Les 5 fonctions requiert d'etre executees avant que la fonction 1 reinterroge la io card pour y lire les donnees.
En gros, ce seront 5 threads a la "queuleuleu" qui attendront chaque fois le jeton du precedent threads. Moi je voudrais faire qqch de facon a ce qu'aucun threads attends (du style la fonction 1 s'execute tout le tps, je dois lire tout le tps la io card, pas seulement toutes les 1 sec (tps de la boucle peut etre) ).
Bref eclaircicez moi sur vos idees parce que la jvois pas trop  
 
Bref, je voudrais que la machine 2 puissent vraiment tout faire en meme tps (recevoir, envoyer, faire ses calculs)

personne ?

Tu dois reflechir differemment : les 5 threads vivent leur vie indépendamment des autres, il n'y a pas d'ordre défini d'éxécution des différentes fontions. Ce sont les mutex qui garantissent que les données dans le buffer ne seront pas perdues. Donx dans chaque fonction, chaque accès au buffer doit être protégé par un mutex. Ensuite c'est l'OS qui décidera tout seul de l'ordre dans lequel les threads travailleront. Il faut donc prévoir, dans la fonction qui li dans le buffer, le cas où celui-ci est vide.
Maintenant dis-toi bien que si ta machine est monoprocesseur, elle ne peux faire qu'une chose à la fois, il est impossible de faire tout en même temps.

 
super. Merci, j'ai mieux compris   ... bon j'embraye sur les threads !