Serveur TCP - Chat avec salons

Bonsoir,

Je voudrais faire un serveur en C TCP, je voudrais faire quelque chose comme un chat, mais avec des salons.

Un joueur se connecte créer un salon, des joueurs rejoignent et peuvent discuter entre eux.

Condition importante, Je dois utiliser des threads.

Actuellement :

J'ai une structure joueur ou je stocke le descripteur du client. ( entre autres )
J'ai une structure salon ou je stocke une liste de joueurs. ( entre autres )

1) Jutilise la fonction select je surveille mes descripteurs, quand un client envoie le code de création de salon je le stocke dans une instance salon

2) Je crée un threads salon ( en lui passant ladresse du salon précedemment crée ).

-Ma question est la suivante comment dans le thread salon surveiller uniquement les descripteurs des joueurs qui y sont présent ? poll select ?
Sachant que je peux en ajouter depuis le main a chaque fois qu'un client demande a y rentrer.

- Ais-je une solution alternative tel que utiliser un thread par client ?

Merci d'avance

Salut,

tu dois utiliser les threads ? On essaye généralement de s'en débarasser :koi:
Tu devrais favoriser poll à select s'il est disponible sur ta plateforme : http://bousk.developpez.com/cours/re...erveur/#LIII-C

Citation:

---

comment dans le thread salon surveiller uniquement les descripteurs des joueurs qui y sont présent ?

---

Euh bah en traitant uniquement les sockets des clients dans le salon en question :weird:

Citation:

---

Ais-je une solution alternative tel que utiliser un thread par client ?

---

C'est une fausse solution qui n'entraîne que des problèmes : flood du serveur si trop de clients, latences, synchronisation et locks à outrance

Bonsoir,

Un thread par salon est une bonne idée (beaucoup plus qu'un thread par client) à condition, là encore, qu'il n'y ait pas des milliers de salons simultanés (ce qui peut encore arriver sur des serveurs destinés à fonctionner en production).

Mais quel que soit le cas de figure (y compris celui où tu n'utilises pas de thread du tout), à chaque fois que tu appelles select(), tu dois marquer au préalable tous les descripteurs à surveiller dans ton ensemble avec FD_SET. Tu peux donc organiser ta surveillance comme tu l'entends, mais l'avantage avec les salons est qu'ils fonctionnent en tout-ou-rien : soit personne ne parle et dans ce cas, on peut mettre le thread en sommeil, soit quelqu'un intervient et là, il faut relayer le message à TOUS les sockets participant au salon.

Donc, tu fais le bilan des sockets de tous tes clients connectés, tu renseignes dans un tableau par salon les descripteurs des participants et tu entres dans ta procédure, qui est la même pour tous tes threads : choix du bon tableau en fonction du salon émulé, puis ajout de tous les descripteurs du tableau avec FD_SET, ton appel à select(), lecture des sockets débloqués et réémission des messages reçus vers tous les descripteurs de ce même tableau. Si tu veux faire propre, tu surveilles aussi les descripteurs en écriture pour éviter qu'un client un peu long à la détente bloque tout le salon, mais ça complique un peu la chose.

Si tu atteins le stade où tu dois gérer des milliers de clients ET des milliers de salons, alors tu reviens à une architecture globale (dans laquelle c'est a priori le même processus qui relaie le tout, quel que soit le client et quel que soit le salon) et tu te sers des threads uniquement pour répartir la charge, en laissant le soin à l'administration de choisir le nombre maximum de threads s'il le souhaite et en choisissant par défaut le nombre de cœurs du CPU de la machine sur laquelle ton programme tourne, par exemple, ou encore le nombre de terminaisons réseau… Tu peux alors répartir tes connexions entre tes threads. Il reste intéressant de les regrouper quand même par salon histoire d'éviter que certains participants reçoivent un message et pas d'autres en cas de défaillance mais, là encore, à condition que le tout soit équilibré (qu'il n'y ait pas un salon qui accuse 99 % du trafic à lui seul, ni une personne ayant rejoint tous les salons à la fois).

Bonsoir,

Tout d'abord merci pour vos réponses :).

Donc pour l'instant, quand un client se connecte il rejoins ou crée un salon déterminé, je l'ajoute a la liste des joueurs du salon (cf struct), je passe sa socket en non bloquant (fcntl) et dans le thread salon je parcours sans cesse les descripteur et regarde si il y a quelque chose à lire ( ça me parait pas terrible du tout ... ).

Et quand un joueur en salon parle ça réveille le select du main mais je tiens pas compte du message ....

Avec cette solution tout marche mais bon...


Il faut que fasse appel à select dans chaque salon et je surveille juste mes descripteur en salon ?
Et je les retire du select du main ?


J'ai pas précisé c'est un jeux de quizz avec chat, mais ça fonctionne pareil :^)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Mes structures :   typedef struct{ char *id; char *pseudo; int socket_joueur; int idsalon; int score; int repondu; int pret; int etat; int rang; //0 Joueur 1 Admin }Joueur;   typedef struct{ int nombreInfos; char *code; char *infos; }Message;   typedef struct{ char question[TAILLE_BUFFER-7]; char reponse[TAILLE_BUFFER-7]; }Question;   typedef struct { char* nom; int etat; int id; Question questions[NBR_QUESTIONS]; Joueur joueurs[NBR_JOUEURS]; int nbr_joueurs; }Salon;

---

Peu importe où tu fais ton select, il faut en faire un par socket c'est tout, puis il faut dispatcher les données reçues.
Le faire dans chaque salon a peu de sens imo, surtout si le client n'est pas forcément dans un salon.
Ton histoire est le candidat parfait pour cet article, c'est un cas similaire à l'exercice que j'avais donné à mes étudiants et j'y présente une implémentation d'un serveur qui répond à ça et devrait pouvoir supporter aisément plusieurs dizaines/centaines de joueurs. J'opte pour une solution non bloquante, mais tu peux l'adapter à l'utilisation de select ou poll sans difficulté.

A la limite si tu prévois des milliers d'utilisateurs, une première optimisation simple sera de grouper les utilisateurs par salon et faire le select par salon. Les utilisateurs sans salon seront alors membre d'un super-salon global pour les regrouper.