Discussion :

[ChriGoLioNaDor]

Bonjour,

J'aimerais r�aliser un programme g�rant les acc�s � un serveur. Mon soucis ne vient pas directement du C++, mais plutot d'un probl�me th�orique :

Mon programme �coute un port donn�. Lorsqu'il re�oit quelque chose, il traite la demande en direct : en gros il re�oit un identifiant, et un mot de passe, il v�rifie dans la BDD s'il existe, puis retourne un r�sultat au client.

Ma question est de savoir ce qu'il arrive, si pendant ce traitement, une ou plusieurs autres demandes arrivent? Seront-elles mises dans une file d'attente (un genre de pile FIFO) automatiquement par le syst�me, ou au contraire ces demandes seront elles simplement ignor�es, tant que le traitement de la premi�re demande n'est pas termin�?

Quelle solution apporter? Mettre un thread qui ne fait qu'�couter le port en permanance, et ajouter le pointeur vers cet ordinateur dans une pile manuellement? Mais le soucis est toujours le m�me si d'autres demandent arrivent pendant ce temps (en cas de tr�s forte affluance).... Mettre plusieurs threads �coutant plusieurs ports? Mais encore faudrait-il que le client sache quel port est disponible...

Qu'en pensez-vous?

Je sais que le temps de traitement �tant tr�s court (quelques fractions de secondes), le probl�me ne devrait pas se produire tr�s souvent. Cependant, j'aimerais savoir s'il est possible que cela arrive, et s'il on peux l'�viter.

Merci d'avance pour vos r�ponses!

[M�dinoc]

Les connexions non satisfaites sont mises en file d'attente, selon le second param�tre de listen().
Au-del�, je ne sais pas ce qui est cens� se passer: Peut-�tre que la connexion est explicitement refus�e, ou que le serveur ne r�pond simplement pas (poussant le connect() � r�essayer automatiquement jusqu'au timeout)

[zais_ethael]

Pour ce genre de situation, il y a bien une architecture optimale.
Celle-ci consiste mettre en place un thread qui attend de nouvelles connexions. Lorsqu'il y a une demande qui arrive, il passe la socket client � un thread faisant partie d'un pool de thread. Un pool de thread en gros c'est un nombre limit� de threads qui tournent en permanence. On peut en r�server un mais il ne sera � nouveau disponible que quand il aura termin� sa tache. Cette solution pr�sente le double avantage multi utilisateur+limitation du nombre de connexions (indispensable pour un serveur r�sistant).
Bon, m�me si c'est ce qu'il y a de mieux, ce n'est pas forc�ment simple � faire
Alors je te propose deux autres solutions:
- M�me principe que plus haut mais il n'y a pas de pool. C'est � dire que pour chaque connexion entrante un thread est cr��. G�n�ralement pour des dossiers scolaires �a fonctionnera toujours bien.
- Un serveur monothread. Le serveur re�oit une demande, fais le traitement et renvoie la r�ponse. En dehors du fait que c'est la pire solution point de vue performance, il est imp�ratif que ton protocole soit d�connect�, c'est � dire qu'il n'ait aucun besoin de maintenir une connexion permanente (donc comme http mais pas du tout comme ftp). Et oui, si une demande arrive pendant que ton serveur traite une autre demande elle sera mise en attente. Il n'y a que l'hote distant qui pourra d�cider de laisser tomber si le d�lais d'attente est trop long (une dizaine de secondes, �a ne signifie pas qu'il soit agr�able pour l'utilisateur d'attendre dix secondes!).
PS: laisse tomber cette id�e de plusieurs ports, on a tous fait ce genre d'erreur de conception au d�but mais avec le recul c'est vraiment ridicule.

[ChriGoLioNaDor]

Merci pour vos r�ponses.

Pour r�sumer la "meilleure" solution :
- 1 thread s'occupe d'�couter un port
- Ce thread principal ajoute la socket � une liste des demandes en attente (liste accessible � partir des autres threads)
- x threads s'occupent de traiter 1 � 1 chaque demande list�e dans cette liste.

On est bien oblig� de passer par une liste non? Tu n'en parles pas, mais je suppose que ce serait plus simple que de devoir � chaque fois trouver un thread disponible (sans parler du cas � pr�voir si tous les threads sont d�j�s occup�s)...


Par contre tu disais qu'en terme de performance, un monothread �tait la pire solution, mais je ne vois pas pourquoi : je connais le principe du thread, qui est de r�aliser des actions en parall�le. Par contre, en terme de performance, je doute qu'il y aie un gain : entre 3 threads qui tournent en permanance et donc se partagent en trois la puissance de calcul du processeur, et dont il faut du temps pour switcher entre chaque thread, et 1 seul utilisant tout la puissance de calcul du processeur, et sans temps de switch, l'avantage reviendrait logiquement au monothread
Idem en termes de m�moire : un seul thread consommera moins de m�moire vive que 3 tournant en permanance

Ai-je mal compris quelque chose?

[millie]

Il faut bien comprendre que d�s que l'on fait intervenir des threads, il y a des difficult�s importantes qui arrivent (il faut que l'application soit multithread safe).

Si les traitements clients a effectu�s sont l�gers, il est possible d'utiliser un select sur l'ensemble des sockets et d'avoir une application monothread performante.

Par contre, d�s qu'il y a des traitements lourds (par exemple envoi d'un fichier, attente pendant un certain temps), il est conseill� de faire intervenir un thread � ce moment lent.

Souvent, les gens ne se prennent pas la t�te et font un thread par client : il est toujours possible de limiter le nombre de client pour �viter que l'application rame (donc le nombre de thread).


Il faut savoir que contrairement au processus, le basculement entre deux threads est nettement plus rapide qu'entre deux processus (d'un ordre de 30 je crois), donc ce n'est pas vraiment un soucis.

Faire intervenir des threads peut �galement simplifier conceptuellement l'application.


A toi de voir

[zais_ethael]

On est bien oblig� de passer par une liste non? Tu n'en parles pas, mais je suppose que ce serait plus simple que de devoir � chaque fois trouver un thread disponible (sans parler du cas � pr�voir si tous les threads sont d�j�s occup�s)...

Tout d�pend de la conception du pool de thread, que l'on concevra g�n�ralement de mani�re g�n�rique. Il peut par exemple �tre fait, comme tu le sugg�re, avec une queue de taille limit�e, la on a pas vraiment une limite du nombre de connexion mais du nombre de demandes, et on repart dans le protocole d�connect�. Un pool de thread simple avec limite du nombre de connexions sera en g�n�ral fait en jouant avec des mutex/s�maphores.

Par contre tu disais qu'en terme de performance, un monothread �tait la pire solution, mais je ne vois pas pourquoi : je connais le principe du thread, qui est de r�aliser des actions en parall�le. Par contre, en terme de performance, je doute qu'il y aie un gain : entre 3 threads qui tournent en permanance et donc se partagent en trois la puissance de calcul du processeur, et dont il faut du temps pour switcher entre chaque thread, et 1 seul utilisant tout la puissance de calcul du processeur, et sans temps de switch, l'avantage reviendrait logiquement au monothread
Idem en termes de m�moire : un seul thread consommera moins de m�moire vive que 3 tournant en permanance

Ai-je mal compris quelque chose?

Tu te trompes, tu ne vois pas toutes les subtilit�s. Ta logique serait bonne si le role d'un serveur �tait de recevoir de petites donn�es, faire de gros calculs dessus et puis renvoyer une petite r�ponse. Je ne dis pas que �a n'existe pas, mais en g�n�ral on se servira d'une calculatrice pour �a .
Le plus souvent un serveur a pour but de distribuer ou de stocker des informations, � partir de fichier pour les cas simples, d'une base de donn�es la plupart du temps. C'est � dire que le temps de calcul ne vaut pas le centi�me du temps transfert client->serveur+transfert serveur->bd+temps de traitement bd+transfert bd->serveur+transfert serveur->client. Un serveur passe la plupart de son temps � attendre, d'o� l'utilit� du multithread, parcequ'un thread qui attend ne ralentis pas les autres.
Qui plus est, il faut penser � tous les utilisateurs. Il est bien plus �quitable d'avoir 10 utilisateurs simultan�s qui recoivent leur r�ponse en m�me temps plutot que de faire attendre �ternellement ceux qui ont eu le malheur d'arriver en dernier. Imagine un serveur ftp, avec de gros fichiers qui prennent plusieurs heures pour le transfert, tu imagines si tu devais attendre aussi longtemps avant que la reception de ton fichier ne commence?

[ChriGoLioNaDor]

Oui en effet, en cas de traitement long (transfert de gros fichiers par exemple, ou encore attente d'une r�ponse du client), ou d'actions simultan�es (on veux pendant le transfert afficher une barre indiquant le pourcentage d'avancement), le multithread est obligatoire ou presque.

Je parlais surtout de mon cas : un programme autonome qui ne s'occupe que de recevoir login+mdp, fait une recherche dans une BDD pour savoir si tout est OK, puis renvoie une r�ponse (par exemple un identifiant unique, ou tout simplement un bool�en). Il n'y a donc aucun traitement long, � part � la limite l'acc�s � la BDD, qui se fait en local.

Dans ce cas pr�cis, je serais plutot contre la cr�ation d'un thread par client : le temps de sa cr�ation et de sa destruction risque de ne pas �tre n�gligeable par rapport au temps d'ex�cution...

Par contre en effet, la cr�ation de x threads permanants et d'un thread "d'�coute" pourraient �tre une autre solution envisageable, mais j'essaie justement de voir s'il y aurait un gain r�el dans ce cas pr�cis. Mais d'un cot�, il est vrai que cela permettrait aussi de ne pas bloquer le programme en cas de soucis avec un client (transfert des donn�es anormalement lent, mauvaise communication, ...).


PS : je vais r�viser mes mutex/s�maphores. Je connais ces termes, mais ne me rappelle plus leur utilit� pr�cise, depuis le temps ^^. C'est bien ce qui permet de cr�er des sections critiques (par exemple pour acc�der et modifier les donn�es de ma liste) ? :p