Nous travaillons sur les programmes prog00_server.cpp et prog01_txt_client.cpp.

L'objet de cette première étape consiste en la mise en place d'une paire de programmes client/serveur TCP.
L'essentiel des algorithmes concernant la génération et l'utilisation des blocs de données est fourni sous forme de commentaires dans chacun des deux programmes✍.
Il ne s'agit alors que de compléter ce qui permet la communication entre client et serveur.
Dans le programme serveur il ne faut, pour l'instant, compléter que ce qui concerne cette première étape.

Lorsque le programme serveur est invoqué de cette façon : [laurier10] $ ./prog00_server 9988 ↵ host 'laurier10.enib.fr' waiting for text connections on port '9988'... il nous rappelle le nom de notre de machine ainsi que le port que nous avons choisi arbitrairement sur sa ligne de commande (>1024).
Sur d'autres terminaux nous pouvons nous connecter par ssh à des machines voisines afin de solliciter notre serveur en lançant des clients TCP : [laurier11] $ ./prog01_txt_client laurier10 9988 ↵ Un message nous indique que le code a été compilé pour la mise au point ; dans ce cas les mesures de performances et d'énergie ne sont pas significatives.

Si nous reconstruisons nos programmes exécutables en demandant au compilateur d'optimiser le code généré $ make rebuild opt=1 ↵ et que nous relançons le serveur, alors les mesures obtenues auront plus de sens, par exemple : [laurier10] $ ./prog00_server 9988 ↵ host 'laurier10.enib.fr' waiting for text connections on port '9988'... starting iterations... 120 blocks in 5.0288 s (23.8626 block/s, 42.1323 Joules) [laurier11] $ ./prog01_txt_client laurier10 9988 ↵ running during at least 5 s... 120 blocks in 5.0289 s (23.8621 block/s, 54.2042 Joules)

Nous travaillons sur les programmes prog00_server.cpp et prog02_bin_client.cpp.

En ce qui concerne le programme client, il s'agit cette fois-ci de reprendre exactement la même structure que dans le programme précédent mais en substituant la communication textuelle par un transfert direct des octets constitutifs du bloc de données.
Le programme serveur devra être adapté en conséquence sans pour autant perdre la possibilité d'utiliser la communication textuelle précédente.
Il devra donc surveiller avec crs::select() deux ports TCP à la fois afin que les connexions sur l'un d'eux provoquent un dialogue textuel alors que les connexions sur l'autre seront consacrées à un dialogue binaire.
En nouvelle fois, l'essentiel des algorithmes concernant la génération et l'utilisation des blocs de données est fourni sous forme de commentaires ; il ne s'agit que de compléter ce qui permet la communication entre client et serveur.
Il faudra veiller cependant à prendre les précautions nécessaires quant à l'ordre des octets lorsqu'il est question de transmettre des données binaires par le réseau.

Le lancement du programme serveur attend désormais deux numéros de port sur sa ligne de commande. [laurier10] $ ./prog00_server 9988 8877 ↵ host 'laurier10.enib.fr' waiting for text connections on port '9988'... host 'laurier10.enib.fr' waiting for binary connections on port '8877'... Sur d'autres terminaux nous pouvons nous connecter par ssh à des machines voisines afin de solliciter notre serveur en lançant des clients TCP : [laurier11] $ ./prog02_bin_client laurier10 8877 ↵ Un message nous indique que le code a été compilé pour la mise au point ; dans ce cas les mesures de performances et d'énergie ne sont pas significatives.

Si nous reconstruisons nos programmes exécutables en demandant au compilateur d'optimiser le code généré $ make rebuild opt=1 ↵ et que nous relançons le serveur, alors les mesures obtenues auront plus de sens, par exemple : [laurier10] $ ./prog00_server 9988 8877 ↵ host 'laurier10.enib.fr' waiting for text connections on port '9988'... host 'laurier10.enib.fr' waiting for binary connections on port '8877'... starting iterations... 476 blocks in 5.00202 s (95.1616 block/s, 23.7293 Joules) [laurier11] $ ./prog02_bin_client laurier10 8877 ↵ running during at least 5 s... 476 blocks in 5.00206 s (95.1607 block/s, 32.5882 Joules) Le nombre de blocs traités par seconde est bien plus grand que lorsque nous communiquions en transformant nos données en texte.

Au delà des performances en terme de durée, nous pouvons comparer les dépenses énergétiques des processeurs pour effectuer le même traitement selon nos deux solutions.
En fixant arbitrairement le nombre de blocs à traiter✍, nous obtiendrons par exemple : [laurier10] $ ./prog00_server 9988 8877 ↵ host 'laurier10.enib.fr' waiting for text connections on port '9988'... host 'laurier10.enib.fr' waiting for binary connections on port '8877'... starting iterations... 200 blocks in 9.91488 s (20.1717 block/s, 69.2589 Joules) starting iterations... 200 blocks in 1.81161 s (110.399 block/s, 8.81107 Joules) [laurier11] $ ./prog01_txt_client laurier10 9988 200 ↵ running 200 iterations... 200 blocks in 9.91495 s (20.1716 block/s, 96.1862 Joules) [laurier11] $ ./prog02_bin_client laurier10 8877 200 ↵ running 200 iterations... 200 blocks in 1.81161 s (110.399 block/s, 11.8247 Joules) La différence de performances se traduit par une différence de consommation énergétique (en Joules) considérable.

Remarquez que la solution de formatage retenue pour la version textuelle est extrêmement simple : nous générons des textes de longueur fixe pour décrire chaque valeur numérique.
Cela permet de ne pas avoir à aborder la complication de l'analyse d'un texte à longueur variable.
En effet, dans un tel cas il serait nécessaire de découper le texte selon les séparateurs pour extraire ensuite chaque valeur numérique, ce qui constituerait une charge de travail encore plus lourde pour la machine✍.

Les machines de Labo de l'ENIB sont interconnectées par des switches assurant une communication à 100 Mb/s.
Ce débit n'est pas très élevé et nos programmes de communication passent finalement beaucoup de temps à attendre que les données circulent.
Si nous utilisions une communication à 1 Gb/s, les différences de performances entre les différentes solutions seraient encore plus marquées.
En particulier, il serait possible, dans le cas de la communication binaire, de ne pas effectuer la permutation des octets si le client et le serveur utilisent le même ordre des octets pour représenter les entiers.
Il suffit pour ceci qu'ils s'échangent au début de la communication des entiers représentant une valeur connue à l'avance sans permuter l'ordre de leurs octets ; si leurs représentations sont identiques après réception, cela signifie qu'aucune permutation n'est nécessaire pour la suite de la communication entre ces deux interlocuteurs.
Cette modification est laissée à titre d'exercice d'approfondissement✍.