Sockets et thread

Version imprimable

12/06/2012, 17h50
Neckara

Sockets et thread

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?
12/06/2012, 20h12
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 :

Citation:

- comment choisir le nombre maximal de client par thread ?

Alors que

Citation:

- 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.

Citation:

- 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..

Citation:

- 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 ;)
12/06/2012, 20h40
Neckara

Citation:

Envoy� par Trademark

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.

Citation:

Envoy� par Trademark

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.

Citation:

Envoy� par Trademark

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.

Citation:

Envoy� par Trademark

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").

Citation:

Envoy� par Trademark

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.

Citation:

Envoy� par Trademark

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.

Citation:

Envoy� par Trademark

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^^

Citation:

Envoy� par Trademark

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?

Citation:

Envoy� par Trademark

Bonne chance ;)

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

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.
12/06/2012, 23h06
Trademark

Citation:

Envoy� par Neckara

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.

Citation:

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.

Citation:

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.

Citation:

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.

Citation:

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.

Citation:

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.

Citation:

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.

Citation:

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

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 ;)
13/06/2012, 07h20
Neckara

Citation:

Envoy� par Trademark

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).

Citation:

Envoy� par Trademark

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.

Citation:

Envoy� par Trademark

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.

Citation:

Envoy� par Trademark

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.
13/06/2012, 07h58
Trademark
Je suis d'accord avec ce que tu as �crit, juste une chose :

Citation:

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 :D

Citation:

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:

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:

1 2 3 4 5 6 lock(mutex); produit... signal(nest_plus_vide); unlock(mutex);
13/06/2012, 08h40
Neckara
Citation:

Envoy� par Trademark

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

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.:aie:
Citation:
Envoy� par Trademark

Code:

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:

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?
13/06/2012, 12h57
Trademark
Citation:

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:

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...
13/06/2012, 13h28
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:

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.
13/06/2012, 13h46
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�.
13/06/2012, 13h55
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.