Discussion :

[samball]

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

[Médinoc]

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.

[samball]

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

[bolhrak]

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.

[samball]

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

[pseudocode]

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é.