Discussion :

[skeud]

Bonjour tout le monde,

Je me lance dans la programmation d'un serveur mmo. Le but étant de créer un prototype capable de gérer une centaine de client à la fois.
Je me heurte à un problème qui semble récurent où les réponses sont très divers et varié.

J'ai un serveur qui va tout gérer de son coté (pas de calcul coté client etc....).

_ Connection des clients.
_ Réception des données du client.
_ Envois de données vers le client.
_ Affectation de la map et tout le tralala dont à besoin un jeu.

J'ai trois approches possible:
On multithread le tout (une thread par fonctionnalité donc 4 au total).

On multithread rien du tout (tout est gérer via un select et le timer du select).

On fait du moitier-moitier, la gestion des clients d'un coté, la gestion de la map et le tralala de l'autre.




J'ai juste commencé la conception du serveur, donc je n'ai pas pu faire de test de charge sur une de ces trois parties.

Je cherche donc un initié qui aurait déjà fait des tests de charge sur une des trois possibilités et me donne son avis.

Je voulais aussi savoir les rapports "cout de dev"/"robustesse de la solution".

Configuration:
linux, C++, gestion des socket bas niveau (read/write/accept/select, pas d'api).
Un pic de connection simultané espéré à une centaine de client.
Un échange de tram de maxi 10ko.
pc portable classique, mais suffisant pour ce genre de demande (oui je précise la machine car évidamment, pour plus de perf, on prend un nouveau serveur très performant, mais c'est pas le but final). Une machine simple devrait suffir à gérer une centaine de client simultané.

[imperio]

Je vais te presenter les avantages et inconvenients de chaque methode, tu n'auras qu'a choisir apres celle qui te convient le mieux.

Tout multithreade :

- pas de consommation CPU si pas de client
- plus grande reactivite sur machine avec plus de coeurs (et donc plus lent sur machine moins puissante logiquement)
- chaque client se gere lui meme, ca facilite la gestion de chacun
- comme chaque ressource doit etre copiee, ca risque d'etre un peu lourd au final en RAM

Juste select :

- si tu veux gerer un timer, c'est plus complique qu'avec les threads et tu auras une consommation CPU "minimum" permanente (pas tres important mais ca vaut le coup d'etre cite)
- toutes les donnees sont centralisees autour d'une seule boucle donc t'as vraiment interet a bien t'y prendre
- pas de threads en attente ou inutiles

Melange des deux :

- c'est a peu pres la meme chose que le tout threade
- si une ressource doit etre utilisee par tous les threads en meme temps, ca pourra creer des lags si il y a beaucoup de demande

Voila, je pense avoir fait une petite description qui t'aidera a t'orienter dans ton choix. Personnellement j'opterais pour un melange des deux mais ce n'est que mon avis.

[skeud]

Je pensais aussi à utiliser un mélange des deux, ça me semble le plus approprié, le seul truc qui m'embète c'est de me rendre compte plus tard que cette solution n'est pas la plus adapté pour mon projet, c'est surtout pour ça que j'avais besoin de résultat de benchmark sur ces solutions pour savoir la moins couteuse en temps de dev rapport au nombre de clients gérable par solution