Discussion :

[Invité]

Bonjour ,

Je vous explique mon soucis .

J'ai mes deux programmes clients serveurs fonctionnant sous TCP IP ( langages C/C++ )

Pour l'instant , le client peut envoyer des commandes au serveur à l'aide de socket , qu'il exécutera localement , enverra au client les infos et donc lui les recevra .

Cependant , j'aimerais réaliser cela à l'aide de socket indépendante ( donc faire du multi-thread ) , chacune ayant un rôle , par exemple une qui s'occupe de l'envoie , une qui reçoit , une qui s'occupe de la gestion des erreurs etc ..

Donc je me demandais de quel façon je pourrais faire tout cela .
Mutex ? Sémaphores ? Comment s'occuper de la gestion des erreurs ( renvoie de 0 ou -1 ) etc ..

J'espère que vous saurez me guider !
Merci d'avance

[ternel]

Bonjour

C ou C++?, il faut choisir (et ne pas poster dans les deux…)

[imperio]

Pour la gestion des sections dites critiques dans la gestion des threads on aurait plutôt tendance à utiliser les mutex (qui ne sont que des sémaphores au final). Cependant sache la fonction select existe (man linux, man windows). Et te permettra de faire un programme sans thread si tu veux.

[dutycorpse]

Bonjour,

Pour le multipthread jette un coup d'oeil au niveau des pthreads pool et tu y trouveras ce que tu veux normalement.

[Bktero]

Pour l'instant , le client peut envoyer des commandes au serveur à l'aide de socket , qu'il exécutera localement , enverra au client les infos et donc lui les recevra .

Cependant , j'aimerais réaliser cela à l'aide de socket indépendante ( donc faire du multi-thread ) , chacune ayant un rôle , par exemple une qui s'occupe de l'envoie , une qui reçoit , une qui s'occupe de la gestion des erreurs etc ..

Cela a t-il vraiment du sens ?

Côté client, le flow est :

1. j'envoie une commande
2. j'attends la réponse
3. je traite les données
4. je recommence

Côté serveur, tu as quelque de semblable.

A priori, ce ne sont pas des tâches parallèles mais bien séquentielles. Si tel est bien le cas, alors tu t'orienteras plutôt vers un thread serveur par client. Si le client envoie une liste de commandes et reçoit les réponses au fur et à mesure (une sorte de file de commande côté serveur) alors ta solution est adaptée.

Il faut bien identifier ton problème pour choisir l'architecture la plus adaptée.

[karastojko]

Vous pouvez séparer l'acceptance des sockets et des requêtes des clients. L'acceptance est réglé par un thread. Chaque requête est transformé dans un message qui est mis dans un queue. Dispatcher prends les messages et les exécutes par les threads differentes de thread pool. Comme une démonstration j'ai creé un exemple de chat sur http://www.alepho.com/index.php?do=coding&date=20110702. On utilise Poco bibliothèque pour les sockets, mais le principe est même. Le texte est en anglais parce que français n'est pas ma langue maternelle.