Discussion :

[Richard Cypher]

Bonjour,

Je me renseigne sur la manière concevoir un serveur qui puisse tenir la charge avec énormement de clients connectés en même temps (dans les 3k ou 4k utilisateurs).

Je réfléchis à la manière d'implémenter l'architecture d'un serveur de jeux massivement multi-joueurs. Pour l'instant je me concentre uniquement sur le chat.

J'ai déja réalisé des mini-serveus multi-threads de tchat , je trouve le concept du muti-thread pas mal . Mais habituellement ce qu'on voit sur tous les exemples sur le net ou ce que l'on nous enseigne en cours c'est de créer un thread pour chaque client qui se connecte au serveur, et c'est ce thread qui sera en charge de la communication pour le client.

Le soucis que je vois dans une architecture comme celle-ci , c'est que si on a 4k clients qui se connectent au serveur , il va falloir créer 4k threads , et que le système devra switcher entre tous les threads , dans ces conditions je pense que le serveur sera incapable de tenir la charge ?

Combien de threads un gros serveur( 2*quadri coeurs) peut supporter avant que les performances s'effondrent ?

J'ai entendu parler des "pools de thread" , es que cela pourrait résoudre le problème , comment cela s'utilise t'il ?

Peutêtre que l'utilisation des threads n'est pas une bonne solution dans ce genre de problème ? dans ce cas quel type d'architecture utiliser ?

Dans les mmo on voit souvent plusieurs "serveurs" ou l'on se connecte qui sont indépendants.
Je voyais la gestion d'un serveur de mmo comme cela :

Plusieurs petits serveurs logiciels qui prennent en charge chaque aspect du jeux mais qui tournent tous sur le meme serveur matériel.

- Serveur logiciel (processus donc) pour la prise en charge du tchat.
- Un autre pour la gestion des déplacements et des combats
- Un autre pour la gestion d'une base de donnée
(Dans ce cas commnent ils communiquent entre eux ?)

Ou alors es qu'en fait ce sont plusieurs serveurs mais qui sont cachés à l'utilisateur qui n'en voit qu'un seul .

Ou enfin tout est dans un seul processus qui tourne sur une seul machine. Dans ce cas comment les différents modules sont ils gérés , avec des threads ou encore un autre système peutêtre ?


J'espère qu'il y aura quelques membres du forum calé dans ce domaine, et je vous remercie d'avance pour vos réponses .

(je post ici car je développe en java)

[divxdede]

Salut,

Une architecture qui consiste à dédier un thread a chacun de tes clients ne peut pas te permettre de monter en charge serainement.

Si utiliser les Socket (java.io) est simple, pour un serveur imposant, tu devras te tourner vers des solutions utilisant des api non bloquante (java.nio)

Avec une api bloquante (java.io) on doit dédier un thread par client afin de pouvoir attendre l'arrivée d'un message.

L'avantage avec java.nio est de pouvoir mettre en pause un thread et qu'il soit reveillé dés qu'un événement arrive (quelque soit le client). Ce qui permet de faire la même chose qu'avec java.io mais avec beaucoup moins de threads.

Un serveur réalisé sur java.nio gérera mieux la montée en charge (nombre d'utilisateurs).

Il existe quelques librairies utilisant nio t'évitant de mettre profondément les moins dans nio.

Les plus répandues sont mina (apache), grizzly (sun).

Je développe également une API réseau utilisant nio : ObjectServer

Ensuite, selon le jeu que tu développes, tu dois reflechir à ton protocole de communication, voir si plusieurs canaux sont nécessaires.

Par exemple un canal en UDP pour l'échange de données "volatile" comme la position des joueurs et un canal en TCP pour l'échange de données plus stricte.

Ensuite tu as des algorithmes coté client qui peuvent "lisser" les défauts d'une communications. Dans le cas d'un échange UDP pour les positions des joueurs, il se peut qu'à un moment ou à un autre les messages soient perdus.

Si le client arrive à extrapoler les mouvements des autres joueurs par rapport aux dernieres informations connues, le client pourra continuer de donner un "mouvement" aux autres joueurs. Lorsque le client recevra les nouvelles données, il n'aura plus qu'a apporter la correction nécessaire par rapport a son extrapolation.

Bref, tout ca pour dire qu'il y a plusieurs facettes pour économiser un serveur.

Séb.

[Richard Cypher]

Donc avant tout utiliser la "nouvelle"(pas récente finalement^^) api d' entré sortie pour avoir de meilleur performance , ok.

Pour toi il faut quand même utiliser des threads , mais en restreindre leurs nombres , et éviter d'en créer et de les détruire à tout va pour économiser les resssources.

Donc faire une gestion fine des threads , mais ca veux dire combien de threads ? un par coeur physique /virtuel du processeurs ?
En gros si le pc a un double proc quadri-coeurs avec l'hyperthreading , se limiter à 16 threads ?

Es qu'il y des exemples de shéma qui explique comment bien concevoir un seveur avec java.nio (on sait jamais ^^). En gros je vois pas comment il faut que se soit organisé.

Si tu entends par canal uniquement un protocol différent , je pense que je n'utiliserai pas udp , j'ai besoin que les informations envoyées soit fiable a 100%. Enfin a première vue , je verai plus udp utilisé dans un fps.

Pour "mon jeu" , enfin pour l'instant yen a pas je réfléchis plus sur la conception technique de ce genre de produit , le mien s'apparente plus a un jeu de type wow. Donc pas forcement une latence extrêmement basse , mais surtout une fiabilité dans la communication , que si le joueur clic sur une attaque puis ensuite sur une autre que l'ordre soit bien respecté. Et meme pour les déplacements je pense qu'il veut mieux que ce soit fiable , mais c'est vrai que cela demande réflexion.

Je vois dans ton api , que tu donnes la possibilité d' envoi par le réseau d' objets java. Je me dit que c'est surement pas une option que je devrais utiliser pour ce genre de jeux non ? Ca ferait surement chuter les performances ?

En parlant de "coûts" , la compression avec gzip , ou des communications avec ssl c'est viable pour un serveur de ce type ?
En gros gzip permet de réduire la bande passante utiliser mais en contrepartie un cout supplémentaire en cpu . Et ssl sécurité accru mais plus de temps cpu utilisé ainsi que de bande passante. Qu'es tu en penses ?

Sinon pour en revenir au découpage en plusieurs modules du serveur . Ca me semble une bonne idée ? ( le tchat , les combats/deplacements , un module qui met a jour les fichiers/ou une bdd, ect ... ).

Mais comment tu organiserais ca toi ? Pour que le serveur arrive à transmettre les messages aux joueurs qui communiquent entre eux , tout en faisant les calculs pour les combats, prendre en compte le déplacement des joueurs , prévenir les autres joueurs du changement de position d'un joueur et mettre à jour les données du jeu dans la bdd sans que le serveur s'effondre.

Pas dans le détail , mais plutôt comment organiser tout ces aspects/modules dans leur globalité ?

Merci encore pour ta réponse.

[millie]

Donc faire une gestion fine des threads , mais ca veux dire combien de threads ? un par coeur physique /virtuel du processeurs ?
En gros si le pc a un double proc quadri-coeurs avec l'hyperthreading , se limiter à 16 threads ?

Il ne faut pas oublier que normalement, la plupart des threads seront endormis. Il faut voir en fonction des traitement effectués => s'il y a beaucoup d'acquisition de ressources (lock, lecture bloquantes...), les threads passeront leur temps à dormir du coup tu peux augmenter leur nombre.

[Richard Cypher]

Il ne faut pas oublier que normalement, la plupart des threads seront endormis. Il faut voir en fonction des traitement effectués => s'il y a beaucoup d'acquisition de ressources (lock, lecture bloquantes...), les threads passeront leur temps à dormir du coup tu peux augmenter leur nombre.

D'accord , mais dans l'idéal ce serait d'avoir toujours un nombre de thread actif égal au nombres de coeurs physique ou virtuel de la machine ?

[wiztricks]

D'accord , mais dans l'idéal ce serait d'avoir toujours un nombre de thread actif égal au nombres de coeurs physique ou virtuel de la machine ?

Sans parler d'ideal, pour profiter de tous les processeurs il faudra au moins un nombre équivalent de processus ou de threads "actifs".
"actifs" = qui consomment du CPU (intelligement s'entend). Leur nombre est inférieur ou égal à celui des threads ou des processus existants/crées dans le système.

[divxdede]

D'accord , mais dans l'idéal ce serait d'avoir toujours un nombre de thread actif égal au nombres de coeurs physique ou virtuel de la machine ?

Pas vraiment, tu peu avoir plus de thread actif que de coeurs.
L'objectif étant de pouvoir développer tes process indépendant pouvant être effectué en //
Ensuite que ton serveur puisse rééllement les traités en // ou si il doit scheduler tes threads pour pouvoir les servir tous ce n'est qu'un détails.

Il n'est pas rare qu'un serveur d'application dispose de plusieurs centaines de threads.

[wiztricks]

Il ne faut pas oublier que normalement, la plupart des threads seront endormis. Il faut voir en fonction des traitement effectués => s'il y a beaucoup d'acquisition de ressources (lock, lecture bloquantes...), les threads passeront leur temps à dormir du coup tu peux augmenter leur nombre.

S'il y a de la contention, il ne sert à rien d'augmenter le nombre de threads.
L'ideal est d'avoir la possibilité d'effectuer le plus grand nombre de traitement possible en parallèle et de pouvoir utiliser la capacité CPU/IO en modulant le nombre de threads crées. (c'est ici qu'on retrouve peut être la définition d'un pool de threads).
- W