Discussion :

[Neckara]

Bonjour,

J'aimerais faire un jeux en ligne mais je ne suis pas sûr de l'architecture à utiliser au niveaux des échanges clients/serveurs.

EDIT :
Après quelques recherches, j'ai lu qu'il vaut mieux faire 1 thread pour X clients et apparemment le temps de traitement des traitements n'est pas le plus important.

Le solution reviendrait alors à faire niveau serveur :
- un/plusieurs threads pour tout ce qui déclenche une action en fonction de l'horaire.
- un thread pour les connexions
- un thread d'administration
- un thread pour X clients

Au début de chaque paquet, on met un int pour savoir quelle fonction doit traiter les données reçu (tchat, jeux, ...)

De là, j'aurais trois questions :
- comment choisir le nombre maximal de client par thread ?
- peut-on faire en sorte que le thread d'administration ai un niveau de gentillesse plus bas que les autres ? (le serveur est sous débian)
- dans quels cas est-il intéressant de créer un autre socket par clients ainsi qu'un thread spécifique pour traiter les données reçu?

[Trademark]

Salut,

Je ne suis pas sûr de savoir ce que fait le thread d'administration fait par rapport à celui qui reçoit les connexions.

Tu dis :

- comment choisir le nombre maximal de client par thread ?

Alors que

- un thread pour X clients

Un ou plusieurs ?

En tout cas, je ferais un thread qui fait un select (ou équivalent) sur les opérations bloquantes : accept, read,... Et pour chaque client tu utilises un buffer, lorsque la totalité des données ont été reçues (délimité par un caractère de fin ou autre), tu mets ce buffer dans une file style producteur/consommateur. Les consommateurs seront un pool de threads, et ces threads ne devront pas utiliser d'opérations bloquantes (reservées au premier thread). Ça permet de ne pas limiter le nombre de client au nombre de thread.

Pour ce qui est du nombre de thread, ça dépend un peu, je pense qu'il faut faire des tests, mais généralement on conseille le nombre de coeur.

Sinon tu peux également utiliser une bibliothèque comme Boost.Asio dédié au réseau.

- peut-on faire en sorte que le thread d'administration ai un niveau de gentillesse plus bas que les autres ? (le serveur est sous débian)

C'est quoi un niveau de gentillesse ? La priorité ? Si oui il existe des fonctions pthreads qui remplissent ce job, mais attention aux problèmes liés à l'utilisation des niveau de priorité comme l'inversion de priorité, etc..

- dans quels cas est-il intéressant de créer un autre socket par clients ainsi qu'un thread spécifique pour traiter les données reçu?

On a de toute façon un socket par client non ? Si la question est d'utiliser un nouveau thread pour chaque socket, ce n'est pas performant, car ton serveur ne tiendra pas la charge si trop de monde est connecté. Si tu mets une limite, les clients ne pourront pas toujours se connecter alors qu'il se peut que certains autres ne fassent rien. Et finalement, la création d'un thread est couteux donc vaut mieux utiliser un pool.

Bonne chance

[Neckara]

Je ne suis pas sûr de savoir ce que fait le thread d'administration fait par rapport à celui qui reçoit les connexions.

Le thread d'administration écoute sur un port différent de celui utilisé pour les connexions normales, ceci permet d'ajouter un léger plus en matière de sécurité. En plus comme il est prioritaire sur celui de connexion, cela permet de se connecter en admin plus facilement si le serveur commence déjà à saturer.

Un ou plusieurs ?

ça dépend du nombre de client, un thread pour X clients, donc si on a 2X clients, on fera 2 threads.

En tout cas, je ferais un thread qui fait un select (ou équivalent) sur les opérations bloquantes : accept, read,... Et pour chaque client tu utilises un buffer, lorsque la totalité des données ont été reçues (délimité par un caractère de fin ou autre), tu mets ce buffer dans une file style producteur/consommateur. Les consommateurs seront un pool de threads, et ces threads ne devront pas utiliser d'opérations bloquantes (reservées au premier thread). Ça permet de ne pas limiter le nombre de client au nombre de thread.

J'utilise la SFML 2.0 avec les selecteurs donc les selects sont déjà pris en compte dedans. Par contre pour ne pas utiliser d'opérations bloquantes, est-ce que tu inclus aussi les mutex ? Dans un contexte multithreads je serais bien obligé d'en utiliser.

Pour ce qui est du nombre de thread, ça dépend un peu, je pense qu'il faut faire des tests, mais généralement on conseille le nombre de coeur.

Mon serveur de test est mono-coeur il me semble (je n'ai pas envie de payer un vrai serveur pour le moment). Quand je devrais aller vers des performances plus élevées, je suppose que le serveur aura entre 4 et 8 coeurs, je pense donc que 8 threads actifs est corrects (au pire je défini une variable de paramètre "nombre de thread").

Sinon tu peux également utiliser une bibliothèque comme Boost.Asio dédié au réseau.

J'aimerais au possible me limiter à la SFML et à mysql.h.

C'est quoi un niveau de gentillesse ? La priorité ? Si oui il existe des fonctions pthreads qui remplissent ce job, mais attention aux problèmes liés à l'utilisation des niveau de priorité comme l'inversion de priorité, etc..

En effet, c'est bien les priorité. Qu'est-ce que l'inversion des priorité? Je dois avouer que j'en ai jamais entendu parler.

On a de toute façon un socket par client non ? Si la question est d'utiliser un nouveau thread pour chaque socket, ce n'est pas performant, car ton serveur ne tiendra pas la charge si trop de monde est connecté.

Je pensais plutôt établir deux sockets par client, un pour le jeux et un pour le tchat par exemple. Avec un thread pour gérer x clients au niveau du jeux et un thread pour gérer x clients au niveau du tchat. Mais avec ta solution des rédacteur/consommateur, cette question n'a plus lieu d'être^^

Si tu mets une limite, les clients ne pourront pas toujours se connecter alors qu'il se peut que certains autres ne fassent rien. Et finalement, la création d'un thread est couteux donc vaut mieux utiliser un pool.

Mais les autres qui ne font rien risquent à tout moment de faire quelque chose et ainsi saturer le serveur.
La solution serait de gérer une "pile" de connexions, si le serveur sature, on déconnecte le dernier connecté. On peut ainsi avertir dès la connexion les joueurs qu'ils sont sur une connexion "instable" si il y a déjà plus de X joueurs connectés.
Par contre comment détecter le moment de saturation?

Bonne chance

Merci pour ta réponse et tes précieux conseils, je commence à y voir un peu plus clair maintenant


EDIT : tu parles de pool de threads, j'aimerais être sûr d'avoir bien compris ce que tu me dit :
1 producteurs : un thread lisant les sockets.
X consommateurs : threads bloqués par un sémaphore dans qu'il n'y a rien à consommer.

[Trademark]

Le thread d'administration écoute sur un port différent de celui utilisé pour les connexions normales, ceci permet d'ajouter un léger plus en matière de sécurité. En plus comme il est prioritaire sur celui de connexion, cela permet de se connecter en admin plus facilement si le serveur commence déjà à saturer.

Je ne suis pas sûre que la priorité changera grand chose si ton serveur sature ^^. Mais c'est vrai que c'est une idée intéressante.

J'utilise la SFML 2.0 avec les selecteurs donc les selects sont déjà pris en compte dedans. Par contre pour ne pas utiliser d'opérations bloquantes, est-ce que tu inclus aussi les mutex ? Dans un contexte multithreads je serais bien obligé d'en utiliser.

Ce que j'inclus, ce sont toutes les opérations bloquantes dépendantes des clients (pour ne pas qu'un client monopolise un thread par une quelconque action). Donc, à priori, les mutex n'en font pas partie vu que c'est de la gestion interne.

Mon serveur de test est mono-coeur il me semble (je n'ai pas envie de payer un vrai serveur pour le moment). Quand je devrais aller vers des performances plus élevées, je suppose que le serveur aura entre 4 et 8 coeurs, je pense donc que 8 threads actifs est corrects (au pire je défini une variable de paramètre "nombre de thread").

Oui généralement on passe le nombre de thread en paramètre au serveur.

En effet, c'est bien les priorité. Qu'est-ce que l'inversion des priorité? Je dois avouer que j'en ai jamais entendu parler.

L'inversion de priorité n'est qu'un problème, ça arrive dans la situation où on a 3 threads à 3 niveaux (niveau 1 le plus bas disons):

* Le thread de niveau 1 prend un mutex ;
* Le thread de niveau 3 demande le mutex (ne peut pas car déjà pris) ;
* Le thread de niveau 2 s'exécute pendant un temps plus ou moins long --> le thread de niveau 1 ne peut plus s'exécuter car il est de niveau trop bas et celui de niveau 3 ne s'exécute pas non plus car il n'a pas le mutex et pourtant il est de plus haute priorité !

Comme tu vois c'est spécifique à un cas. Je ne suis pas sûr que jouer avec les priorités soient une bonne idée dès le départ, mais pourquoi pas.

Je pensais plutôt établir deux sockets par client, un pour le jeux et un pour le tchat par exemple. Avec un thread pour gérer x clients au niveau du jeux et un thread pour gérer x clients au niveau du tchat. Mais avec ta solution des rédacteur/consommateur, cette question n'a plus lieu d'être^^

Oui, en fait l'idée c'est d'organiser le serveur par tâche à effectuer et non par client.

Mais les autres qui ne font rien risquent à tout moment de faire quelque chose et ainsi saturer le serveur.

Ils ne satureront pas plus le serveur qu'un nouvel arrivant ! Le serveur "sature" lorsque le pool de thread ne travaille pas assez vite et que la file P/C grandit.

La solution serait de gérer une "pile" de connexions, si le serveur sature, on déconnecte le dernier connecté. On peut ainsi avertir dès la connexion les joueurs qu'ils sont sur une connexion "instable" si il y a déjà plus de X joueurs connectés.
Par contre comment détecter le moment de saturation?

Je ne suis pas sûr que déconnecter le dernier soit une bonne idée, je pense que le mieux serait de refuser les nouvelles connections.

Pour savoir si on sature, tu peux par exemple regarder à quelle vitesse la file se remplit et à quelle vitesse elle se vide, avec sa taille actuel tu devrais être capable d'imposer des limites. La limite pourrait simplement être un malloc qui échoue.

Merci pour ta réponse et tes précieux conseils, je commence à y voir un peu plus clair maintenant


EDIT : tu parles de pool de threads, j'aimerais être sûr d'avoir bien compris ce que tu me dit :
1 producteurs : un thread lisant les sockets.
X consommateurs : threads bloqués par un sémaphore dans qu'il n'y a rien à consommer.

Lisant et acceptant les connexions + éventuellement autres tâches bloquantes.

Pour les consommateurs, un sémaphore à 1 jeton suffit, donc un mutex, plus les conditions qui vont bien.

Je viens de penser que tu peux éventuellement lire ou faire d'autres choses "bloquantes" dans le pool de thread en mettant un timeout de 0 (donc ça ne sera pas bloquant, mais le thread risque de ne pas avoir toutes les informations nécessaires et il faudra alors remettre le buffer dans la file, ce qui peut provoquer indirectement une boucle active : imaginons qu'il n'y ait que une tâche qui ne se complète pas car le client ne répond pas (par exemple) : les threads du pool prendront et remettrons sans arrêt). --> Ce n'est donc pas une bonne idée

[Neckara]

Je ne suis pas sûr que déconnecter le dernier soit une bonne idée, je pense que le mieux serait de refuser les nouvelles connections.

Sinon une autre idée : dès qu'on dépasse une certaine limite X, on met sur file d'attente et en envois régulièrement la position dans la file d'attente.
Dès qu'on redescend en-dessous d'une limite X - k, on recommence à accepter les connexions (pour éviter de passer d'un état à l'autre trop rapidement).

Pour savoir si on sature, tu peux par exemple regarder à quelle vitesse la file se remplit et à quelle vitesse elle se vide, avec sa taille actuel tu devrais être capable d'imposer des limites. La limite pourrait simplement être un malloc qui échoue.

Comme on est en C++, ce serait plutôt un new, mais que la limite soit un malloc qui échoue ne me semble pas une bonne idée, en effet, il est possible que j'ai à faire des allocations qui touche non plus un seul joueur mais l'ensemble du serveur. Voir même des allocations pour l'administration. Je pense donc qu'à une allocation échoué, on déconnecte le joueur ou un joueur au hasard et on recommence.

Pour les consommateurs, un sémaphore à 1 jeton suffit, donc un mutex, plus les conditions qui vont bien.

J'ai du mal à visualiser avec un seul jeton. Je vais essayer de voir si je ne trouve pas quelque chose sur google.

Je viens de penser que tu peux éventuellement lire ou faire d'autres choses "bloquantes" dans le pool de thread en mettant un timeout de 0 (donc ça ne sera pas bloquant, mais le thread risque de ne pas avoir toutes les informations nécessaires et il faudra alors remettre le buffer dans la file, ce qui peut provoquer indirectement une boucle active : imaginons qu'il n'y ait que une tâche qui ne se complète pas car le client ne répond pas (par exemple) : les threads du pool prendront et remettrons sans arrêt). --> Ce n'est donc pas une bonne idée

Les actions bloquantes risquent surtout d'être de l'envoie de paquets TCP. Si le client ne répond pas, on le déconnecte tout simplement.
La réception des données se fera au niveau du producteur.


Je n'avais pas vu que pool était un design pattern, en gros, la classe Manager va contenir une liste de thread et de mutex. A chaque nouvelle production, on libère un des mutex.
Mais je vois mal comment faire si il y a plus de production que de consommateur.

[Trademark]

Je suis d'accord avec ce que tu as écrit, juste une chose :

la classe Manager va contenir une liste de thread et de mutex.

Attention au piège des Manager comme exprimé dans ce billet : http://blog.emmanueldeloget.com/inde...-gestionnaires pour partir sur des bases saines

A chaque nouvelle production, on libère un des mutex.

Non pas exactement. L'ajout et le retrait sont dans une session critique et donc protégé par un même mutex.

Lors du retrait on fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
lock(mutex);
tant que la liste est vide : 
  attendre(mutex, nest_plus_vide); // libère mutex et attend un signal sur nest_plus_vide
 
...
 
unlock(mutex);

Tandis que le producteur fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
lock(mutex);
 
produit...
 
signal(nest_plus_vide);
unlock(mutex);

[Neckara]

Attention au piège des Manager comme exprimé dans ce billet : http://blog.emmanueldeloget.com/inde...-gestionnaires pour partir sur des bases saines

Je dois avouer que je n'ai pas saisi tout l'intérêt.
Il est évident que pour la gestion des threads, je ferais une instance d'une classe et non un design singleton vu que l'utilisation est très locale.
Par contre pour la gestion des logs, je vais devoir utiliser un design singleton (pas de risques de deadlock vu qu'une fonction prend et rend le mutex) vu que je ne peux pas avoir deux caches. (j'en parle un peu ici).

Mais je ne vois pas l'intérêt de dissocier la factory du cache.
De toute façon la factory ne doit pas être accessible en dehors du cache (sinon le cache ne sert plus à rien).
Ce que je fais là est déjà bien en avance par rapport à mes cours, il me manque donc quelques connaissances théoriques à ce sujet.
De plus têtu comme je suis, je ne serais pas convaincu avant d'avoir bien compris et saisi l'intérêt.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
lock(mutex);
tant que la liste est vide : 
  attendre(mutex, nest_plus_vide); // libère mutex et attend un signal sur nest_plus_vide
 
...
 
unlock(mutex);

Tandis que le producteur fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
lock(mutex);
 
produit...
 
signal(nest_plus_vide);
unlock(mutex);

Faut que je réfléchisse et que je regarde un peu plus en détail.

EDIT : on a pas un deadlock? Il prend un mutex puis attends un signal. Le producteur ne pouvant entrer dans le phase critique, il ne peut pas produire donc il n'y aura pas de signal envoyé.
Désolé, mal lu le commentaire. Mais on ne peut pas remplacer le signal par un mutex?

[Trademark]

Désolé, mal lu le commentaire. Mais on ne peut pas remplacer le signal par un mutex?

Non, et pour la simple et bonne raison que tu dois, à un moment ou un autre, attendre que la file ne soit plus vide (si consommateur) ou ne soit plus pleine (si producteur) tout en libérant le mutex 'm' et en le récupérant après.

Ta remarque suppose qu'on doit attendre sur un mutex, or il faudrait faire quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Consommer
lock(m);
 
get_jeton(sema_taille_file);
// consommer
 
unlock(m);
 
// Produire
lock(m);
// produire
 
put_jeton(sema_taille_file);
unlock(m);

Or tu ne peux pas faire ça car si un consommateur rentre dans la section critique "m" pour prendre un jeton, et que la file est vide, il bloque tout le monde.

Essaye les différents cas, et je pense que tu auras toujours un problème de deadlock ou de synchronisation...

[Neckara]

C'est vrai qu'avec des mutex ce n'est pas pratique.

La version avec des sémaphore est, je pense un peu plus simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
sem1.prendre();
 
mutex.lock();
//phase critique
mutex.unlock();
 
sem2.rendre();

Et inversement pour l'autre.

Je n'aime pas trop envoyer de signaux car il faut être sûr que le thread auquel on envoie le signal soit prêt à le recevoir.

[Trademark]

J'ai un doute sur le code du dessus.

Pour ce qui est des "signaux", en fait, on appelle ça un signal dans la terminologie des threads, mais ce n'est pas un signal à proprement parler, comme un SIGINT ou quoi que ce soit. De plus, si tu envois un signal alors que le thread n'est pas en attente, et bien ça ne fait rien du tout !

EDIT : Après refléxion, ce code doit être bon. Par contre, je pense qu'il est moins performant car :

quand tu fais un sem.rendre() tu incrémentes la variable de ce sémaphore, hors pour incrémenter cette variable il te faut un mutex. Quand tu fais un sem.prendre() et que tu ne peux pas tu attends. Conclusion, c'est dans le sem.rendre() qu'on fait un signal pour le thread qui attend dans sem.prendre().

En bref, on déplace juste le problème et tu ajoutes un mutex supplémentaire. Mais la gestion du signal / wait t'es caché.

[Neckara]

Je dois avouer que je ne connaissait pas ce type de signaux.

Par contre il n'y a pas de signaux dans la SFML. Je pense donc utiliser ma méthode avec les sémaphores.

Et le code me semble bien correct.