Je serais intéressé par la programmation d'un serveur qui à la base ressemblerait à un serveur irc, mais avec un gros traitement des utilisateurs, dans le but de leur attribuer des positions sur un terrain, tout ca.
 
Vous m'avez compris, ca ressemble de très près à un jeu de rôle...
 
Je voulais savoir quelle serait, selon vous, l'organisation la plus efficace :
 
 - 1 seul gros thread qui gère tous les clients (10, 100, 1000, ...) et le moteur du jeu
 - 2 threads, un qui gère les clients et un autre le moteur
 - un thread par client, dialoguant avec un gros thread qui gère le moteur
 - toute autre solution à laquelle je n'ai pas pensé (il y en a surement plein)
 
Merci d'avance pour vos idées et vos conseils
 
::madprog::

" - un thread par client, dialoguant avec un gros thread qui gère le moteur "
 
à la trappe

oui, je pencherais plus pour les 2 threads en fait

le pool de thread

je comprends pas bien, pool de thread c'est pas un thread par client ? pourtant tu as dit à la trappe non ?

c'est quoi le pool de thread ?
 
enfin je veux dire, en quoi ca consiste ?

hmm... ca a l'air d'etre un truc qui vient de C# et VB enfin d'après mes recherches sommaires

ça a rien à voir.

bah c'est quoi alors ? ^^

bens c mettons 10 threads frères, qui tapent tous dans une liste de chose à faire...dès qu'un thread a fini, il cherche qqc dans la liste ...si y'a rien, il dort...

oula ca doit etre chaud a gerer une liste comme ca... on met quoi dedans  

pourquoi ce serait chaud ?
 

des tâches

bah je sais pas, qu'est ce que tu appelles une tâche ? un pointeur de fonction ?

tu me fait bien marrer, tu nous fait un topic Algo/Débat théroique, et tu incapable de d'abstraire de quoi que ce soit. Je te dis pool de threads, tu dis que ça va pas que c'est duVB, je dis tâche, tu parles C ...

Récapitulons:
Soit n clients connectés sur le serveur.
Les différentes politiques sont:
 
- 2 threads: le premier gère le moteur, le 2e fait des lectures non bloquantes sur les n sockets; qd il recoit une requête sur une socket, il la traite ou la délègue au moteur.
 
- 1 thread pour le moteur. n threads qui font chacun une lecture bloquante sur une socket, qd ils recoivent qqchose ils traitent ou délèguent au moteur.
Pas l'eden si on a beaucoup de clients connectés je présume.
 
- pool de threads: les threads frères composant le pool traitent les taches de la liste. Un unique thread fait des lectures non bloquantes sur les n sockets et rajoutent les taches dans la liste?
 
C'est bien ça?

désolé... je voulais voir ce que vous auriez fait, et quand tu me parles du pool de thread, je cherche tout de suite comment l'appliquer... donc je pense à un language, et je ne vois pas du tout ce qui peut faire office de tâche ici...

cassidy, oui

 
bein une tâche, c'est toi
 
 
blague à part, c'est par exemple les clients en attente d'être servis

comment je l'attendais la blague...

ca semble évident la def d'une tache si t'y réfléchi...c qqc qu'un thread doit faire....
 
par ex pour un server web, une tache c'est s'occuper d'une requete...t'a une liste de requetes, et des threads qui tapent dedans...

ouais, vu comme ca, je comprends

J'ai commencé à faire la même choses (plus ou moins) et j'ai opté pour :
 
- Un thread par client (mais qui gère tout le perso, pas seulement sa connection)
- Dans le thread principal, je ne gère que la map, et chaque thred "client" pointe vers une case de cette map
- Un thread de "thick" (défini la fin d'un tour si tu compte limiter le nombre d'actions dans le temps, redonner des HP en dormant, etc.)
- Les mobs sont gérés dans des threads identiques à ceux des joueurs, à l'exception qu'à la place d'une connection il y a un petit moteur d'IA qui les fait se déplacer et réagir avec leur entourage.
 
Je pense que mon système peut être très lourd, mais permet de vraiment s'élcater pour ce qui est de l'IA des mobs ; on peut vraiment imaginer des mobs qui évoluent comme les joueurs, à la recherche de matos et d'xp, qui se souviennent de trucs du genre "tiens, c'est toi le méchant qu'a butté ma femme ! tiens, meurts !"
 
Sinon, tu peux faire une recherche de "mud" sur le net, tu trouveras des serveurs open source tous fait pour ce type de jeu.

1 thread par gars !!!!
 
y'a des OS qui ont des limites de thread non ?

bah chais pas. de toute façon sur ce type de jeux, quand t'es plus de 50 c'est le bordel alors

bon, certes, après tu rajoutes les 100 000 threads de mobs et tu risque d'avoir un problème mais bon, c'est à tester

PS: en fait je voulais faire autant de threads que de gars / mobs car selon un certain nombre de critères, je voulais qu'une action dure plus ou moins longtemps pour chaque perso / mob. Et avec une boucle ca pose problème, parceque du coup t'es obligé de la faire tourner à fond la caisse pour que tous les persos fassent leur action au moment réellement imparti, ce qui provoque une charge élevée pour rien, alors qu'avec des threads il suffit de mettre un sleep paramètré dans la boucle des actions.