WEBVTT 00:00.140 --> 00:07.550 Ainsi, à la ligne 140, le serveur a reçu du client les données à traiter. 00:07.970 --> 00:12.170 Le serveur doit maintenant comprendre quelles données le client a réellement envoyées. 00:13.280 --> 00:18.710 Nous avons donc supposé que le client a envoyé les données. 00:20.480 --> 00:27.800 De type test struct t c'est-à-dire que le client a envoyé deux variables entières non signées. 00:27.830 --> 00:30.340 A et B, à droite. 00:30.350 --> 00:37.790 Par conséquent, le serveur va diffuser les données reçues du client dans le même type de structure. 00:38.720 --> 00:42.590 Pour que notre serveur puisse lire les données envoyées par le client. 00:43.660 --> 00:48.520 N'oubliez donc pas que le serveur doit savoir quelles données le client a envoyées. 00:49.960 --> 00:58.990 Ainsi, à l'étape 9, nous vérifions la condition spatiale selon laquelle si le client envoie les deux valeurs 00:58.990 --> 01:07.330 entières à zéro, le serveur considérera qu'il s'agit d'une condition spatiale et fermera la connexion 01:07.330 --> 01:09.610 avec le client. 01:09.640 --> 01:16.060 Dès que le serveur voit que le client a envoyé les deux valeurs sous la forme zéro zéro. 01:16.900 --> 01:17.670 C'est vrai ? 01:17.680 --> 01:24.640 Supposons donc dans cet exemple que le client n'ait pas envoyé les deux valeurs à zéro. 01:24.910 --> 01:26.920 Que fera donc le serveur ? 01:28.200 --> 01:34.320 Le serveur ne fera rien, mais il traitera les données envoyées par le client et renverra le 01:34.320 --> 01:35.730 résultat au client. 01:36.360 --> 01:39.850 Notre serveur est donc très simple. 01:39.870 --> 01:46.530 Il a la fonctionnalité suivante : quelles que soient les données qu'il reçoit du client, c'est-à-dire quelles 01:46.530 --> 01:53.760 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 01:53.760 --> 01:55.710 renvoie la somme au client. 01:56.460 --> 01:57.120 C'est vrai. 01:57.120 --> 02:00.800 Le serveur a donc pris une variable appelée struct result. 02:02.460 --> 02:02.970 C'est vrai. 02:02.970 --> 02:07.110 Voyons donc la définition de cette structure, qui est très simple. 02:07.110 --> 02:14.040 Il va simplement stocker le résultat de l'addition des valeurs A et B envoyées par le client. 02:15.270 --> 02:15.780 C'est vrai. 02:15.780 --> 02:24.840 Ainsi, à la ligne 154, le serveur calcule la somme des valeurs de A et B et stocke le résultat 02:24.840 --> 02:25.710 dans. 02:27.140 --> 02:29.330 Résultat structure t structure. 02:31.150 --> 02:37.330 Une fois que le serveur a fini de traiter les données envoyées par le client, il invoque 02:37.330 --> 02:44.230 l'appel système send to, car il veut maintenant renvoyer le résultat au client. 02:45.160 --> 02:52.810 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 02:52.810 --> 02:57.460 désormais avec le client et procède à un échange de données avec ce dernier. 02:57.820 --> 03:04.090 Le deuxième argument de l'appel système send to est en fait un pointeur sur le tampon de réponse que 03:04.090 --> 03:06.190 le serveur renvoie au client. 03:06.670 --> 03:12.100 Le troisième argument est la taille du tampon que le serveur renvoie au client. 03:12.790 --> 03:15.310 Et le quatrième argument est toujours nul. 03:15.340 --> 03:24.190 Vous pouvez supposer que le cinquième argument est à nouveau l'identité du client vers lequel le serveur effectue cette communication. 03:25.090 --> 03:25.780 C'est vrai. 03:25.960 --> 03:30.130 Et cette structure a déjà été remplie en acceptant l'appel du système. 03:30.550 --> 03:35.860 Et l'argument final n'est rien mais il s'agit de la taille de la structure socket. 03:36.310 --> 03:42.070 Ainsi, en utilisant l'appel système "send to", notre serveur a renvoyé la réponse au client. 03:43.050 --> 03:49.800 La valeur de retour de l'appel système send to est à nouveau le nombre d'octets envoyés par le serveur. 03:50.700 --> 03:53.850 Le serveur imprime donc simplement le nombre d'octets envoyés. 03:55.770 --> 04:04.320 Le serveur a renvoyé le résultat au client et vous pouvez voir que le serveur retourne au début 04:04.320 --> 04:08.300 de la boucle interne, n'est-ce pas ? 04:08.310 --> 04:16.130 Cela signifie que le serveur, après avoir envoyé une réponse au client, prépare à nouveau le tampon de données 04:16.140 --> 04:20.190 et attend à nouveau les données suivantes du client. 04:21.260 --> 04:25.190 C'est vrai, parce que cela invoquera à nouveau l'appel système "Recevoir de". 04:25.980 --> 04:29.230 En fait, notre serveur est une boucle infinie. 04:29.250 --> 04:30.750 C'est notre serveur. 04:30.750 --> 04:37.650 Après avoir renvoyé la réponse au client, le serveur attend à nouveau la demande de données suivante du 04:37.650 --> 04:39.620 client, et ainsi de suite. 04:39.630 --> 04:44.430 Notre serveur est donc un cycle infini de communication avec ce client. 04:45.110 --> 04:52.100 Supposons maintenant que ce client particulier veuille mettre fin à une connexion avec notre serveur. 04:52.220 --> 04:58.940 Pour ce faire, le client envoie la valeur de A et B comme zéro au serveur. 04:59.420 --> 05:06.320 Vous pouvez donc voir ici que le serveur détectera que les valeurs de A et B envoyées par le client sont 05:06.320 --> 05:07.160 nulles. 05:07.370 --> 05:14.780 Le serveur ferme donc la connexion avec le client et sort de la boucle interne. 05:15.970 --> 05:16.960 Vous pouvez donc le constater. 05:16.990 --> 05:20.290 Où ira le contrôle après cette pause ? 05:21.160 --> 05:29.020 Le contrôle ira au début de la boucle externe, tandis qu'une boucle qui est le serveur drainera l'ensemble des 05:29.020 --> 05:30.220 données lues. 05:30.520 --> 05:36.790 Le serveur remplira à nouveau le jeu de lecture avec le descripteur de fichier de la socket principale et le serveur est maintenant 05:36.790 --> 05:39.100 bloqué sur l'appel système select. 05:39.310 --> 05:45.550 Cela signifie que le serveur en a terminé avec le client précédent et qu'il attend maintenant la demande 05:45.550 --> 05:49.240 d'établissement de connexion d'un autre client. 05:49.270 --> 05:57.370 Cela signifie que le serveur a fini de servir le client précédent et qu'il attend maintenant la nouvelle 05:57.370 --> 06:00.910 demande de connexion du nouveau client. 06:01.090 --> 06:08.680 Le nouveau client peut être le même que le précédent, mais l'ancien client doit à nouveau établir 06:08.680 --> 06:11.140 la connexion avec le serveur. 06:12.750 --> 06:20.010 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 06:20.010 --> 06:27.450 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 06:27.450 --> 06:34.950 revient au début de la boucle interne while one et est à nouveau bloqué sur l'appel système "Recevoir". 06:35.250 --> 06:39.090 En d'autres termes, notre serveur fonctionne désormais comme un esclave du client. 06:40.880 --> 06:45.860 Il reçoit les données du client, les traite et renvoie le résultat au client. 06:45.860 --> 06:50.510 Et il se bloque à nouveau pour recevoir les nouvelles données du client. 06:50.630 --> 06:57.470 Et ce cycle se poursuit indéfiniment, à moins que le client n'envoie la valeur de A et B comme zéro. 06:58.180 --> 07:03.700 Lorsque le serveur reçoit la valeur zéro pour A et B, il ferme la connexion 07:03.700 --> 07:13.240 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 07:13.240 --> 07:20.350 "select", c'est-à-dire que le serveur est maintenant prêt à servir le nouveau client. 07:20.590 --> 07:26.380 Nous avons donc abordé les étapes 9 et 10, c'est-à-dire que le serveur ferme la connexion 07:26.380 --> 07:31.140 du client lorsqu'il reçoit la valeur de A et B égale à zéro. 07:31.150 --> 07:35.650 Une fois la connexion fermée, le serveur passe à la cinquième étape. 07:35.680 --> 07:40.000 C'est le début de la boucle extérieure while one. 07:41.940 --> 07:42.540 C'est vrai. 07:43.710 --> 07:48.870 Nous avons donc abordé les dix étapes de la mise en œuvre d'un serveur TCP typique. 07:49.230 --> 07:56.160 Dans l'exemple suivant, nous améliorerons la conception de ce serveur et nous discuterons de la mise en 07:56.160 --> 08:01.170 œuvre d'un serveur TCP capable de gérer plusieurs clients en même temps. 08:01.350 --> 08:03.510 C'est-à-dire que notre serveur peut. 08:04.190 --> 08:10.280 Traite les demandes de plusieurs clients en même temps et peut répondre à ces clients en 08:10.280 --> 08:11.120 même temps. 08:12.800 --> 08:20.450 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 08:20.450 --> 08:24.590 avec le client actuel avec lequel il est en train d'établir une communication. 08:25.610 --> 08:29.480 Il s'agit donc d'un inconvénient majeur de la conception de ce serveur Dhcp.