Nous travaillons sur le programme prog01_http_perf.cpp.

L'objet de cette première étape consiste en la réalisation d'un serveur HTTP très rudimentaire dans un premier temps.
En complétant la fonction main() de prog01_http_perf.cpp vous mettrez en place un serveur TCP multi-threads.
Au début de la fonction dialogThread() exécutée par ce serveur, vous procéderez à l'analyse de la requête HTTP formulée par un client.
Vers la fin de cette même fonction vous traiterez le cas de la fourniture d'un simple fichier HTML lorsque la ressource "/" est demandée.
Remarquez qu'il n'est pas question de chercher si un tel fichier existe ; nous délivrerons toujours le même, "http_perf.html", qui est déjà présent dans le répertoire courant.
Comme tout dernier cas de la fonction dialogThread() il restera à délivrer un message d'erreur lorsqu'une requête ne peut être satisfaite.

En l'état, vous devriez constater que lorsque le navigateur sollicite votre serveur avec l'URI http://localhost:9876/ (en supposant que votre serveur écoute sur le port 9876), il affiche bien la page HTML attendue (ou votre message d'erreur si vous demandez une autre URI).
Toutefois, l'application en javascript que contient cette page HTML émet des requêtes auxquelles votre serveur ne sait pas encore répondre.
Étudiez alors la fonction d'initialisation window.onload du fichier http_perf.html afin de constater la mise en place du moyen de communication (XMLHttpRequest) et son usage (émission/réception).

Pour que cette application fonctionne, il faut à nouveau compléter la fonction dialogThread() de façon à ce qu'elle traite ces deux requêtes :

Remarquez que HTTP est un protocole sans état, et rien ne garantit que plusieurs requêtes en provenance du même client arrivent forcément sur la même connexion TCP (même si c'est autorisé et en pratique c'est très souvent le cas).
Puisque nous voulons effectuer quelques mesures de temps et d'énergie pour traiter toute une série de blocs, il nous faut garder une trace de ces mesures entre chaque nouvelle requête.
C'est pour cette raison que ces trois types de requêtes contiennent dans leur URI un identifiant unique choisi aléatoirement par le client (symbolisé par ?id=XXXX ici).
Le serveur se sert de cet identifiant pour retrouver les données qu'il avait précédemment mémorisées pour ce même client.
Toutes les indications pour prendre en compte ces deux types de requêtes sont détaillées dans des commentaires aux endroits appropriés de la fonction dialogThread().

Une nouvelle sollicitation de votre serveur par le navigateur doit maintenant conduire à une application fonctionnelle avec de nombreuses requêtes de blocs et une requête de fin.
Veillez à ne pas trop produire d'affichages superflus dans la console car le grand nombre de requêtes risque de rendre illisibles les quelques affichages utiles.
En particulier, un message doit vous rappeler que le code a été compilé pour la mise au point et que dans ce cas les mesures de performances et d'énergie ne sont pas significatives.

Si nous nous débarrassons des affichages superflus et que nous reconstruisons notre programme exécutable en demandant au compilateur d'optimiser le code généré $ make rebuild opt=1 ↵ nous devrions voir le serveur afficher des mesures plus significatives.
Pour cela, il faut se connecter par ssh à une machine voisine afin d'y exécuter le serveur, par exemple : [poivre10] $ ./prog01_http_perf 9876 ↵ host 'poivre10.enib.fr' waiting for connections on port '9876'... new connection from 192.168.73.211:54214 --> sending file: http_perf.html --> beginning application with client 930025 --> ending application with client 930025 2x4096 blocks in 10.8333 s (2x378.095 block/s, 63.5394 Joules) Ce serveur distant peut alors être sollicité par le navigateur de notre machine locale [poivre11] $ firefox http://poivre10:9876/ ↵

Nous travaillons sur le programme prog02_ws_perf.cpp.

La solution employée pour les échanges applicatifs de la réalisation précédente est contraignante pour plusieurs raisons : Le second programme proposé ici vise à réaliser une application similaire à la précédente mais en utilisant le protocole websocket afin de contourner les inconvénients qui viennent d'être évoqués.

Il s'agit dans un premier temps de compléter le programme prog02_ws_perf.cpp en reprenant (par copier/coller puis adaptation) les éléments principaux du programme précédent :

En l'état, vous devriez constater que lorsque le navigateur sollicite votre serveur avec l'URI http://localhost:9876/ (en supposant que votre serveur écoute sur le port 9876), il affiche bien la page HTML attendue (ou votre message d'erreur si vous demandez une autre URI).
Toutefois, l'application en javascript ne parvient pas encore à obtenir une websocket puisque votre serveur ne sait pas encore les gérer.
Étudiez alors la fonction d'initialisation window.onload du fichier ws_perf.html afin de constater la mise en place du moyen de communication (WebSocket) et son usage (émission/réception).

Pour que cette application fonctionne, il faut à nouveau compléter la fonction dialogThread() de façon à ce qu'elle exploite le protocole websocket.
Ceci suit le déroulement suivant : Remarquez que, cette fois-ci, cette succession de messages a lieu sur la même connexion ; de simples variables locales suffisent à représenter l'état courant de l'application.

Une nouvelle sollicitation de votre serveur par le navigateur doit maintenant conduire à une application fonctionnelle qui exploite une websocket pour échanger des blocs de données avec le serveur.
Veillez à ne pas trop produire d'affichages superflus dans la console car le grand nombre d'échanges risque de rendre illisibles les quelques affichages utiles.
En particulier, un message doit vous rappeler que le code a été compilé pour la mise au point et que dans ce cas les mesures de performances et d'énergie ne sont pas significatives.

Si nous nous débarrassons des affichages superflus et que nous reconstruisons notre programme exécutable en demandant au compilateur d'optimiser le code généré $ make rebuild opt=1 ↵ nous devrions voir le serveur afficher des mesures plus significatives.
Pour cela, il faut se connecter par ssh à une machine voisine afin d'y exécuter le serveur, par exemple : [poivre10] $ ./prog02_ws_perf 9876 ↵ host 'poivre10.enib.fr' waiting for connections on port '9876'... new connection from 192.168.73.211:54198 --> sending file: ws_perf.html new connection from 192.168.73.211:54204 --> upgrading to websocket 2x4096 blocks in 8.38273 s (2x488.623 block/s, 45.644 Joules) client disconnected Ce serveur distant peut alors être sollicité par le navigateur de notre machine locale [poivre11] $ firefox http://poivre10:9876/ ↵

Nous constatons sur ces nouvelles mesures, qu'au delà de la simplification du fonctionnement du serveur, nous obtenons des gains de performance et d'énergie grâce au protocole websocket.

Remarquez toutefois que, pour les raisons déjà évoquées à la fin de cette section, le gain constaté dans les salles de Labo de l'ENIB est bien moindre que ce que nous pourrions observer si les machines étaient interconnectées par des switches plus rapides.
En effet, une nouvelle fois nos programmes passent beaucoup de temps à attendre que les données circulent.

N'oublions pas également que les réalisations envisagées ici sont à la base très favorables pour les performances car elles reposent dans les deux cas sur des échanges de données binaires.
Comme nous l'avons déjà étudié dans ce sujet, l'échange de données binaires est bien plus efficace que si nous nous étions reposé sur des échanges textuels (que ce soit avec HTTP ou avec websocket).
Cela mérite d'être rappelé car il est très courant, dans les applications reposant sur HTTP, de s'appuyer sur des formats de données textuels (XML, JSON...) faciles à exploiter grâce à des API déjà fournies mais qui imposent au matériel un surcoût considérable en temps et en énergie.