Discussion :

[LeXo]

Bonjour
Pour emettre et écouter en meme temps sur le serveur

j'ai trouvé 3 choix

les threads
Duplication de process :les fork unix
le multiplexage d'E/S asynchrone

sur quel criteres, je choisis l'une ou l'autre ?

d'avance merci
je regarde le site de Beej'

[koala01]

Salut,

je suis désolé de faire une "réponse de normand", mais... tout dépend entièrement de ce que tu souhaites mettre en place.

J'ai presque la conviction que la préférence d'une des solutions par rapport aux autres deviendra manifeste en cours d'analyse et de conception.

Il n'est d'ailleurs pas impossible que tu choisisse une méthode pour une partie de l'application et une autre pour une autre partie, simplement, parce qu'elle te semblera être la meilleure pour le cas que tu veux gérer

[Feriaman]

Je suis moi-même désolé de ne pas t'être d'une grande aide, dans la mesure où je ne sais pas à quoi tu fais référence lorsque tu parles de "multiplexage d'entrées sorties asynchrones".

Concernant le choix entre Fork et thread, ça beaucoup de comment tes threads/fork vont devoir communiquer entre eux.

Les threads appartiennent au même programme, et notament partagent une certaine zone mémoire. Les fork vivent chacun leur vie de leur coté, (ce qui ne les empèche pas de communiquer).

Dans le cas d'un serveur de dessin coopératif, où plusieurs clients se connectent au même serveur pour dessiner en même temps sur le même tableau, j'imagine que tu utiliseras plutot des thread.

Dans le cas d'un serveur de génération de courbes, ou plusieurs clients se connectent au même serveur pour lui filer des listes de points et recevoir en échange des courbes de données, j'imagine que tu utiliseras plutot des forks.

Bonne chance.


P.S : Jusqu'à présent, tous les serveurs que j'ai codé utilisaient des threads.

[LeXo]

bha merci
ces réponses qui n'en sont pas

m'éclairent quand meme un peu

merci

[koala01]

En fait, il est meme fort vraissemblable que tu préféreras pour la partie "serveur", un peu à l'instar de ce que fait Apache, par exemple (désolé, l'exemple m'est venu à l'esprit bien après mon premier post), lancer carrément un processus séparé pour chaque requete, de manière à ce que le "processus parent" puisse toujours rester à l'écoute du port par défaut.
[EDIT](Ce qui ne l'empeche d'ailleurs pas forcément de lancer plusieurs threads pour gérer une seule requete... je ne suis pas allé assez loin dans son fonctionnement pour être précis sur le sujet )[/EDIT]

D'un autre coté, il n'est pas inenvisageable que tu envisage l'utilisation de threads dans une certaine mesure, et, pourquoi pas, le lancement d'un nouveau processus dans certains cas (comme l'ouverture d'une deuxième fenetre du navigateur)

Enfin, selon les cas toujours, il faudra voir ce qui est le plus efficace au niveau de la transmission des données: multiplexage ou connexion (et transmission) synchrone/asynchrone du client au serveur... Mais cà, cela dépendra de la charge que peut supporter la partie serveur et du temps que tu considère comme admissible entre l'envoi d'une requete et l'obtention du résultat

Finalement, tu vois que ma réponse de normand était un bon résumé du problème, non

[LeXo]

en fait, hier soir j'étais parti sur l'idée d'utiliser des threads pour gèrer la communication.

alors je vais regarder ce qui se fait

mon contexte : systeme embarqué avec un noyau linux