Architecture logicielle

[unkn0wn107]

Classes Principales

1. Server

• Description: Gère les écoutes sur les ports spécifiés et accepte les connexions entrantes.
• Associations: Utilise ConnectionHandler pour gérer les connexions individuelles.

2. ConnectionHandler

• Description: Traite les données reçues des clients et utilise HTTPProtocol pour analyser et répondre aux requêtes.
• Associations: Possède un pointeur vers HTTPProtocol pour déléguer le traitement des requêtes HTTP.

3. HTTPProtocol (classe abstraite)

• Description: Définit une interface pour le traitement des requêtes et des réponses HTTP, permettant l'implémentation de différentes versions du protocole.
• Implémentations: HTTP1_1, HTTP2

4. HTTP1_1

• Description: Implémentation concrète de HTTPProtocol pour HTTP/1.1.

5. HTTP2

• Description: Implémentation concrète de HTTPProtocol pour HTTP/2 (facultatif, pour extension future).

6. ConfigLoader

• Description: Charge et analyse le fichier de configuration du serveur.

7. FileManager

• Description: Gère les opérations de fichier comme lire des fichiers statiques ou stocker des fichiers téléversés.

8. Logger

• Description: Enregistre les événements et les erreurs du serveur.

Classes pour les Fonctionnalités Bonus

9. SessionManager

• Description: Gère les sessions utilisateur, en créant et en suivant les sessions avec des identifiants uniques.

10. CookieManager

• Description: Gère la création, la suppression, et la validation des cookies.

11. CGIHandler

• Description: Gère l'exécution de scripts CGI pour différents types de contenu.

Interactions et Relations

• Server utilise ConnectionHandler pour gérer chaque connexion client.
• ConnectionHandler dépend de HTTPProtocol pour traiter les requêtes selon la version du protocole HTTP.
• HTTPProtocol est une classe abstraite implémentée par HTTP1_1 et potentiellement HTTP2, permettant une flexibilité dans le traitement des requêtes.
• SessionManager et CookieManager sont utilisés par ConnectionHandler pour gérer les sessions et les cookies lors du traitement des requêtes et des réponses.
• CGIHandler est appelé par ConnectionHandler lorsqu'une requête nécessite l'exécution d'un script CGI.

[ZEDIUM-Off]

petit aperçu d'une archi possible. Vous en pensez quoi ?

[unkn0wn107]

Super premier jet !

Classe Config aussi, résultat du ConfigLoader.

Je mettrais aussi un Router et des Route, utilisées par ConnectionHandler, qui dispatche à FileManager (que je mettrais pas au serveur mais à ConnectionHandler) ou à CGIHandler selon la Route et la Config (ConnectionHandler l'utiliserait aussi).

Le logger serait utilisé par quasiment toutes les classes pour centraliser le logging, pas que server.

Pour encore plus découper les responsabilités de HTTPProtocol, je vois bien aussi ces classes dans le game : Request : méthodes pour la parser et accéder aux en-têtes, au corps, etc. Response : méthodes pour définir les en-têtes, le corps, etc.

Utilisations / Relations :

• HTTPProtocol utilise Request et Response.
• HTTPProtocol crée une instance de Request pour stocker les informations de la requête (méthode, URL, en-têtes, etc.).
• HTTPProtocol crée une instance de Response pour stocker les informations de la réponse (code d'état, en-têtes, etc.).
• FileManager, CGIHandler, SessionManager, et CookieManager utilisent Request et Response pour traiter les requêtes et préparer les réponses.
• FileManager peut lire le contenu d'un fichier statique et le stocker dans le body de la Response.
• CGIHandler peut exécuter un script et stocker sa sortie dans le body de la Response.

J'ajouterais aussi un CacheHandler (Cache tout simplement) pour gérer le cache des Response en fonction des Request. Ils parlent pas de Cache dans le sujet mais c'est ce qui fait qu'un serveur web peut rep à pleins de requêtes concurrentes. Ca me parait pas bien complexe : un map de key/value intérrogé à chaque Request qui retourne une Response si la requête exacte a déjà été faite. A voir si on veut implémenter ça ?

J'y mettrais aussi une classe abstraite Middleware pour pouvoir charger des middlewares et ajouter des traitements intermédiaires facilement. Question à se poser si on a des traitements à faire du genre en mandatory ou bonus ?

J'ajouterais bien un ThreadPool pour gérer le multi-threading aussi :

class ThreadPool {
public:
    ThreadPool(size_t poolSize);
    enqueue(Task &task);

private:
    void routine();
    Task[ ] tasks;
    pid_t[ ] workers;
    size_t poolSize;
};

L'intérêt est certains, à voir la complexité que ça amènerait et si on fait ce choix ou pas ?

[unkn0wn107]

Je vous propose d'utiliser la notation Mermaid pour le diagramme de classe. Facile à apprendre et écrire, couramment utilisé et nativement intégré à Github.

Draft v2

Y'a un live editor ici