Hello !
 
Dans un projet, on a un serveur web a faire en C.
 
Il nous a proprosé une architecture qui, selon lui, est bcp + robuste que celle proposée par défaut, a savoir un process maitre qui foirke des qu'un client arrive.
 
Son truc a lui c'est :

• Au lancement du serveur

-Processus qui forke n fois, et tous les threads sont donc en attente.
-Trois etats différents : Eteint, en attente, en cours de traitement
-Le processus maitre se met en attente d'une connexion.

• Si une connexion arrive

-Le processus en attente, le seul, envoie un signal a son thread "voisin", signifiant "Mets toi en attente".
-Si le thread voisin se mets en attente car il était dans le mode éteint, alors il envoie a son voisin, comme une liste chainée , un signal disant "J'ai pris le relais, fait ton execution".
-Si le thread voisin pouvait pas, il relaie au prochain thread la demande d'attente
-Si la demande d'attente a fait une boucle et revient au process maitre, alors il fait un Denial of service.
-Si le signal que quelqu'un arrive au maitre, alors il traite la demande.
 
Point fort :
-Si serveur lancé alors les ressources sont la
-attaques de type "pleins de clients" pas possible
-Les forks planteront jamais si le serveur est lancé ( y en aura pas de fait en live en fait, sauf pour les cgi).
 
La faiblesse :
-Chaque signal va devoir se balader sur chacun des X threads avant de revenir a son maitre, dans les deux cas.
 
Y a moyen d 'avoir un truc plus efficace que cela a votre avis ?
 
Par exemple en incluant *jenesaispascomment* le PID du process maitre en cas d'acceptation... un truc du genre...
 
Vos idées sont les bienvenues. Le but du TP est pas de forcément discuter son truc, c'est moi, personellement, qui m'intérroge a mort.

j'ai pas compris tes thread/fork, ça me semble pas terrible tout ces forks, moi je suis pour un pool de thread éternels qui traitent la file d'attente des requêtes

En gros taz :
-Je dis 10 threads dans la config
-Le serveur se lance et créé les 10 threads d'emblée.
 
parti de la, y a trois états :
-Eteint, ou le processus fait rien
-Attente, ou il écoute sur le port 80 si il y a une requete
-En travail, si il traite une requete.
 
Au départ, tu as 10 threads dont 9 sont en mode éteint et 1 en attente.
 
Les threads sont comme dans une liste chainée ( chacun connait son voisin d'apres ).
 
Si le thread 1, en attente, recoit une demande de connex. Avant le traitement, il va dire au thread 2 "eh, tu me relaie ?" .
 
Si le thread 2 est en mode éteint, alors il prends le relais et dit au thread3 "j'ai pris le relais, dis le a ton voisin". Et l'info va revenir au thread 1 qui va donc dire "OK je peux traiter la commande".
 
Si le thread 2 etait en traitement, il passe la demande de relai au thread 3. Et rebelotte.
 
Si le thread 1 recoit la demande de relais, alors tlm est occupé. Donc il peut pas gérer la requete. Donc denial of service.
 
Tu peux détailler le pools de thread éternels ?

ben tu as un thread de connexion qui accepte les connexions, et dirige les requêtes arrivantes dans une file d'attente (avec un petit traitement quand même). après tu as un pool de threads en nombre fixe qui exécutent les requêtes en attente. producteur->consommateurs en somme

Ohhh ok.  
 
Ca a les memes propriétés que son truc, sauf que ca évite de passer par tous les threads...
 
Bien vu taz
 
D'autres suggestions aussi pertinentes ?

En plus, ton système est tout bête.
 
Tu fais une liste chainée des requetes "a traiter", tu mets un mutex sur la chaine des requetes a traiter pour pas que deux threads se marchent sur les pieds et... ben s'est fini.

 
c'est une méthode standard, testée et approuvée

Je confirme...
 
mais pour le DoS, en fait, vous limitez la taille de la pile a une certaine taille , nan ? Style MAX Pile = NB THREADS et vala... nan ?