Discussion :

[Goundy]

Bonsoir, je poste ce post en étant vachement dégouté, car comme un idiot j'ai commencé le développement d'un serveur en me basant sur (ok la honte) 1 thread par client sans considérer le coût de ceux là.
Avant de vous demander des conseils je vais décrire la nature de mon serveur:
- Jeu de poker avec chat (disposition de canaux + messages privés)
- os: linux & compatible
- mode connecté biensure (tcp)
- Protocol utilisé: Un mini irc-like (vraiment très minimal)
- Nombre de clients que je vise maintenant: 400
- Densité de l'envoi des données: Je dirai similaire à ce qui se passe sur l'irc, donc ce n'est que des petits textes et de même pour le jeux en question que des petites commandes

Ma question:
Que me conseillez vous?
Après certains débats avec quelques personnes sur l'irc, je suis arrivées à une conclusion dont je ne suis absolument pas sur:
- Le processus principal: Accept les connexions entrantes + Gestion de l'authentification des utilisateurs
- thread A: Gestion de tous les clients: Execution des commandes du genre: envoyer un message public ou privée, joindre un canal, changer de pseudo,... etc (des commandes aussi simples quoi)
- thread B: Gestion des PINGs pour kill'er les clients inactifs
Est-ce bien défini?
J'attend vos réflexions avec impatience

Merci

[Médinoc]

1 thread par client, ce n'est pas si rare que ça. C'est un process par client (les si populaires "serveurs-fork") qui bouffe vraiment les ressources.

Ce qu'il faut savoir, c'est que le nombre de sockets qu'on peut passer à select() est limité. Donc, il faudrait voir pour commencer si un fd_set accepte 400 sockets. Si ce n'est pas le cas, tu devras utiliser plus d'un thread pour la communication.

Je ne sais pas trop comment marchent les serveurs basés sur les Thread Pools, mais je pense que le multithread n'est utilisé que pour des opérations longues, et que la communication avec les clients reste centralisée.
Toutefois, il est peut-être possible que les clients soient répartis (genre, X clients maximum par thread de communication)...

[Skyounet]

Je rajouterais de séparer les différentes fonctions par thread aussi.

Un pour le chat
Un pour le jeu

Je pencherais aussi pour un select pour la gestion des clients, mais comme l'a dis Medinoc, il faut regarder quel est le nombre maximal de descripteurs que select accept (FD_SETSIZE).

[Goundy]

Merci pour vos réponses, cependant:

Je rajouterais de séparer les différentes fonctions par thread aussi.
Un pour le chat
Un pour le jeu

Je n'y vois pas l'interêt en fait, autant laisser les deux fontions dans un seul parcequ'en fait c'est pas un jeu 3D ou un gros trucs comme ça. Ce n'est que de la pur bête 2D (clients en delphi/lazarus) et le jeu se déroule en envoyant simplement une commande du type: GAME MISE JOUEUR 1000... etc

Sinon juste une question, une chose que je n'ai pas trouvé dans le man. L'argument 1 de la fonction select représente le plus gard fd + 1.
Que devrai-je mettre dans mon cas? checker la plus grande valeur à chaque création de socket ?

EDIT:

Que pensez vous de la libevent? on m'a dit que c'été plus adapté à utilisé que select .... fin moi je connais pas donc je sollicite votre intervention

[fearyourself]

1 thread par client, ce n'est pas si rare que ça. C'est un process par client (les si populaires "serveurs-fork") qui bouffe vraiment les ressources.

Ce qu'il faut savoir, c'est que le nombre de sockets qu'on peut passer à select() est limité. Donc, il faudrait voir pour commencer si un fd_set accepte 400 sockets. Si ce n'est pas le cas, tu devras utiliser plus d'un thread pour la communication.

Il est limité par FD_SETSIZE qui chez moi vaut 1024.

Jc

[Médinoc]

Je dirais oui, vérifier la plus grande valeur à chaque création (et peut-être destruction) de socket.
Sachant que tu peux mémoriser cette valeur pour ne pas avoir à te retaper toute la liste lors de la création...

Ou bien, tu peux y aller à la barbare et mettre FD_SETSIZE, il me semble.

[Goundy]

Ok d'accord Merci
Et est-ce que quelqu'un s'est déjà servit de la libevent ?
http://www.monkey.org/~provos/libevent/