Ainsi, à la ligne 140, le serveur a reçu du client les données à traiter.
Le serveur doit maintenant comprendre quelles données le client a réellement envoyées.
Nous avons donc supposé que le client a envoyé les données.
De type test struct t c'est-à-dire que le client a envoyé deux variables entières non signées.
A et B, à droite.
Par conséquent, le serveur va diffuser les données reçues du client dans le même type de structure.
Pour que notre serveur puisse lire les données envoyées par le client.
N'oubliez donc pas que le serveur doit savoir quelles données le client a envoyées.
Ainsi, à l'étape 9, nous vérifions la condition spatiale selon laquelle si le client envoie les deux valeurs
entières à zéro, le serveur considérera qu'il s'agit d'une condition spatiale et fermera la connexion
avec le client.
Dès que le serveur voit que le client a envoyé les deux valeurs sous la forme zéro zéro.
C'est vrai ?
Supposons donc dans cet exemple que le client n'ait pas envoyé les deux valeurs à zéro.
Que fera donc le serveur ?
Le serveur ne fera rien, mais il traitera les données envoyées par le client et renverra le
résultat au client.
Notre serveur est donc très simple.
Il a la fonctionnalité suivante : quelles que soient les données qu'il reçoit du client, c'est-à-dire quelles
que soient les valeurs de A et B qu'il reçoit du client ou du serveur, il calcule simplement la somme de ces deux valeurs et
renvoie la somme au client.
C'est vrai.
Le serveur a donc pris une variable appelée struct result.
C'est vrai.
Voyons donc la définition de cette structure, qui est très simple.
Il va simplement stocker le résultat de l'addition des valeurs A et B envoyées par le client.
C'est vrai.
Ainsi, à la ligne 154, le serveur calcule la somme des valeurs de A et B et stocke le résultat
dans.
Résultat structure t structure.
Une fois que le serveur a fini de traiter les données envoyées par le client, il invoque
l'appel système send to, car il veut maintenant renvoyer le résultat au client.
N'oubliez pas que l'appel système send to est également invoqué sur le descripteur de fichier de la socket de communication, car le serveur communique
désormais avec le client et procède à un échange de données avec ce dernier.
Le deuxième argument de l'appel système send to est en fait un pointeur sur le tampon de réponse que
le serveur renvoie au client.
Le troisième argument est la taille du tampon que le serveur renvoie au client.
Et le quatrième argument est toujours nul.
Vous pouvez supposer que le cinquième argument est à nouveau l'identité du client vers lequel le serveur effectue cette communication.
C'est vrai.
Et cette structure a déjà été remplie en acceptant l'appel du système.
Et l'argument final n'est rien mais il s'agit de la taille de la structure socket.
Ainsi, en utilisant l'appel système "send to", notre serveur a renvoyé la réponse au client.
La valeur de retour de l'appel système send to est à nouveau le nombre d'octets envoyés par le serveur.
Le serveur imprime donc simplement le nombre d'octets envoyés.
Le serveur a renvoyé le résultat au client et vous pouvez voir que le serveur retourne au début
de la boucle interne, n'est-ce pas ?
Cela signifie que le serveur, après avoir envoyé une réponse au client, prépare à nouveau le tampon de données
et attend à nouveau les données suivantes du client.
C'est vrai, parce que cela invoquera à nouveau l'appel système "Recevoir de".
En fait, notre serveur est une boucle infinie.
C'est notre serveur.
Après avoir renvoyé la réponse au client, le serveur attend à nouveau la demande de données suivante du
client, et ainsi de suite.
Notre serveur est donc un cycle infini de communication avec ce client.
Supposons maintenant que ce client particulier veuille mettre fin à une connexion avec notre serveur.
Pour ce faire, le client envoie la valeur de A et B comme zéro au serveur.
Vous pouvez donc voir ici que le serveur détectera que les valeurs de A et B envoyées par le client sont
nulles.
Le serveur ferme donc la connexion avec le client et sort de la boucle interne.
Vous pouvez donc le constater.
Où ira le contrôle après cette pause ?
Le contrôle ira au début de la boucle externe, tandis qu'une boucle qui est le serveur drainera l'ensemble des
données lues.
Le serveur remplira à nouveau le jeu de lecture avec le descripteur de fichier de la socket principale et le serveur est maintenant
bloqué sur l'appel système select.
Cela signifie que le serveur en a terminé avec le client précédent et qu'il attend maintenant la demande
d'établissement de connexion d'un autre client.
Cela signifie que le serveur a fini de servir le client précédent et qu'il attend maintenant la nouvelle
demande de connexion du nouveau client.
Le nouveau client peut être le même que le précédent, mais l'ancien client doit à nouveau établir
la connexion avec le serveur.
Vous pouvez donc voir qu'il s'agit d'un serveur qui ne peut gérer qu'un seul client à la fois parce que le serveur
a passé son temps dans la boucle interne while one et qu'une fois qu'il a répondu au client avec le résultat, le serveur
revient au début de la boucle interne while one et est à nouveau bloqué sur l'appel système "Recevoir".
En d'autres termes, notre serveur fonctionne désormais comme un esclave du client.
Il reçoit les données du client, les traite et renvoie le résultat au client.
Et il se bloque à nouveau pour recevoir les nouvelles données du client.
Et ce cycle se poursuit indéfiniment, à moins que le client n'envoie la valeur de A et B comme zéro.
Lorsque le serveur reçoit la valeur zéro pour A et B, il ferme la connexion
avec ce client et retourne au début de la boucle extérieure, alors que le serveur lui-même est bloqué dans l'appel système
"select", c'est-à-dire que le serveur est maintenant prêt à servir le nouveau client.
Nous avons donc abordé les étapes 9 et 10, c'est-à-dire que le serveur ferme la connexion
du client lorsqu'il reçoit la valeur de A et B égale à zéro.
Une fois la connexion fermée, le serveur passe à la cinquième étape.
C'est le début de la boucle extérieure while one.
C'est vrai.
Nous avons donc abordé les dix étapes de la mise en œuvre d'un serveur TCP typique.
Dans l'exemple suivant, nous améliorerons la conception de ce serveur et nous discuterons de la mise en
œuvre d'un serveur TCP capable de gérer plusieurs clients en même temps.
C'est-à-dire que notre serveur peut.
Traite les demandes de plusieurs clients en même temps et peut répondre à ces clients en
même temps.
Dans cette conception particulière, nous constatons que notre serveur ne peut pas servir ou recevoir le nouveau client tant qu'il n'en a pas fini
avec le client actuel avec lequel il est en train d'établir une communication.
Il s'agit donc d'un inconvénient majeur de la conception de ce serveur Dhcp.