Probleme d'Architecture Serveur, comment lier les threads clients au serveur ?

Bonjour
Je suis actuellement en train de travailler sur un serveur de jeu en reseau sous windows.
J'ai simplement une question sur l'architecture global du code.

Chaque thread client(socket) est embedded dans une classe. (chaque nouveau client creer un nouveau thread donc une nouvelle classe cClient)
Cette classe contient par exemple une methode read qui lit sur le reseau (je simplifie le tout)

Le serveur contient une liste de client (map<int id, cClient> par exemple) , et donc autant de thread crée que de client.

Par quel moyen traiter les informationss provenant du réseau grace a la classe principal sachant que le informations arrivent directement dans chaque thread client :

Systeme de Message de Windows (GetMessage etc ? mais je ne sais pas si on peut envoyez des donnees importante)

Mutex et compagnie ?

Merci et a bientot

Personnellement, je ne peux pas beaucoup t'aider, je n'ai pas d'expérience en serveur multi-thread (le seul serveur multi-client que j'aie fait était mono-thread et utilisait WSAAsyncSelect() pour traiter des clients multiples dans le même thread).

Par contre, au sein d'un même processus, tu peux passer autant de données que tu le veux dans un message Windows d'un thread à l'autre : tu passes un pointeur, et hop ça marche.

Oui mais la je risque de me retrouve a devoir ecrire des donnes au meme endroit au meme moment donc mutex ?

Est-ce que je dois changer mon architecture ou pas?

Merci

Si tu choisis du multithread comme tu le souhaite, ces threads finiront par écrire des données au même endroit (sinon je vois mal comment les données vont pouvoir être renvoyées vers tous tes clients :s), donc pas le choix, il va falloir synchroniser tout ça.

Maintenant une manière assez simple de le faire et qui évite de devoir synchroniser partout est de fonctionner avec de queues synchronisés. Les threads qui lisent les données sur les sockets postent tout ça das une queue, et le thread principal vient chercher les messages. Ou tu peux faire une queue par thread et un algo pour choisir dans quelle queue lire le message par le thread principal.

Bien sûr si tno serveur a une archi multi coeur ou multi proc, il peut être intéressant d'avoir plusieurs threads principaux ; mais là il faudra également penser à les synchroniser dans la partie "plus haute" de ton appli.

Dans le cas d'une queue general dans le server, il risque d'avoir des problème car 2 client vont y acceder en meme temps

Et dans le cas d'une queue par client, comment etre sur de traiter les message dans le bon ordre.

A priori la premiere methode m'interesse + cependant comment bloquer proprement l'acces a cette queue ? semaphore ? mutex ?

merci

Citation:

---

Envoyé par samball

A priori la premiere methode m'interesse + cependant comment bloquer proprement l'acces a cette queue ? semaphore ? mutex ?
merci

---

Mutex, c'est leur raison d'etre. Afin d'optimiser il faut garder le mutex le moins de temps possible, donc ton serveur doit prendre le mutex juste le temps de depiler un message de la queue, puis rendre le mutex. Le traitement du message aura lieu une fois le mutex relaché.

Merci beaucoup pour la reponse.
Travaillant sous windows (visual studio) est-ce que l'utilisation de mutex requiert l'inclusion de librairie externe ou autre?

Avez vous des examples simple d'utilisation de mutex (la msdn ne nous a pas forcement aide pour cela)

Cependant existe-t-il une autre methode pour gerer nos informations provenant de nos differents thread client ou les mutex reste la plus courante des solutions.

Merci d'avance

Le plus simple et le plus économique sous Windows, ce sont les CRITICAL_SECTION (équivalent des pthread_mutex_t, local à un processus).

Ça s'utilise avec InitializeCriticalSection(), EnterCriticalSection(), LeaveCriticalSection(), etc.

Tu peux très facilement, en C++, te faire une petite classe RAII qui verrouille une CRITICAL_SECTION et la rend dans son desctructeur.

Sinon tu peux également regarder du côté de la librairie ACE (http://www.cs.wustl.edu/~schmidt/ACE-overview.html) qui contient beaucoup de choses bien utiles (et très bien faites) pour le type de programme que tu souhaites faire.

Citation:

---

Envoyé par Médinoc

Tu peux très facilement, en C++, te faire une petite classe RAII qui verrouille une CRITICAL_SECTION et la rend dans son desctructeur.

---

Donc a chaque fois que je veux lock, j'instancie mon object RAII et pour release (unlock) je detruit (delete?) ce meme object?

Pourquoi ne pas creer une classe RAII, qui initialise ma CRITICAL SECTION dans le constructeur, une methode lock et une methode unlock et dans mon code:

maclass.lock() lorsque je veux locker et vice versa sans jamais detruire mon object RAII.

Qu'en pense tu ?

Merci

Ce que tu dois retenir, c'est que la CRITICAL_SECTION est persistente : Elle est typiquement créée au début du processus, et détruite à la fin. Donc, la RAII sur la CRITICAL_SECTION est secondaire. Possible, mais secondaire.

Ce qui est important, c'est le verrouillage: il FAUT que la CRITICAL_SECTION soit dévérouillée en toute circonstances une fois qu'on en a fini avec. Donc, son verrouillage DOIT être RAII.

Les MFC ont quelques classes qui montrent bien ça. Dans le principe, ça donne un truc de ce genre:

Code:

---

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

//Interface (classe abstraite) class ILockable { public: virtual void lock() = 0; virtual void unlock() = 0; };   //Classe RAII de section critique class CCriticalSection : public ILockable { //... };   //Le plus important : Classe RAII de verrouillage. class CLock { public: CLock(ILockable &lockable) : m_lockable(lockable) { m_lockable.lock(); } ~CLock() { m_lockable.unlock(); } private: ILockable &m_lockable; }

---

Et ça s'utilise ainsi:

Code:

---

1 2 3 4 5 6 7 8 9

CCriticalSection globalCritSeq;   void FonctionQuiABesoinDuLock() { CLock theLock(globalCritSeq);   //Opérer sur les données protégées par globalCritSeq; //... }

---

Edit: Post croisé avec bolhrak.

Ce ne sera pas safe. Imagine que tu acquiers le verrou dans une méthode susceptible de lancer une exception, et que cette exception est lancée avant que le verrou ne soit relâché ?

Le mieux est de :
- lock le mutex dans le constructeur
- unlock dans le destructeur.

Toujours construire ton objet sur la pile, comme ça en cas d'exception, il sera automatiquement détruit.

Mais tu ne peux pas declarer ILockable &m_lockable vu que c'est une interface?

non?

Ben si, puisque c'est une référence.
Et ce n'est pas vraiment une interface, puisqu'il n'y a pas d'interface en C++. C'est juste une classe abstraite.

On a plus ou moins compris ta gestion des critical sections :
Cependant quand faire :
InitializeCriticalSection ?
Nous avons pense a le placer dans le constructeur du CCriticalSection.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

De plus la classe CCriticalSection ressemblera donc a :   class CCriticalSection : public ILockable { private: CRITICAL_SECTION m_cs;   public: CCriticalSection () { InitializeCriticalSection (&m_cs) }   void lock() { EnterCriticalSection(&m_cs); } void unlock() { LeaveCriticalSection(&m_cs); } };

---

Merci de ton aide.

Perso je ne me pose pas de question metaphysique avec les Mutex.
Habituellement j'utilise cette classe la:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

class Mutex {   private: CRITICAL_SECTION cs;   public: void Lock() { EnterCriticalSection(&cs); }   void Unlock() { LeaveCriticalSection(&cs); }   Mutex() { InitializeCriticalSection(&cs); }   ~Mutex() { DeleteCriticalSection(&cs); }   };

---

Eh bien au moins vous êtes d'accord.

samball, tout ce qui manque à ta classe, c'est le destructeur.

Merci beaucoup, j'ai tous compris.

Bonne annee a tous et bonne journee.

moi je trouve le scoped_lock très simple et très pratique.

Avec un nom et un commentaire pareils, c'est du boost ?