WEBVTT 00:00.470 --> 00:03.650 Les gars, nous en avons terminé jusqu'à l'appel du système de leçons. 00:03.950 --> 00:10.400 L'étape suivante est l'initialisation et le remplissage de l'ensemble. 00:13.390 --> 00:20.320 Vous pouvez donc voir que nous avons terminé l'appel système de la leçon. Le serveur entre maintenant dans la boucle infinie 00:20.320 --> 00:22.000 pour servir le client. 00:22.630 --> 00:29.550 Le serveur a la propriété d'être toujours en mesure de servir le client. 00:29.560 --> 00:38.740 Le serveur doit donc être monté de 24 en 7 et c'est la raison pour laquelle la logique du serveur est généralement mise en œuvre à l'intérieur 00:38.740 --> 00:40.810 d'une boucle infinie. 00:40.810 --> 00:42.130 Il s'agit d'une boucle. 00:43.590 --> 00:45.060 En ce moment même. 00:45.060 --> 00:47.100 Rappelez-vous que nous avons fixé. 00:47.940 --> 00:53.790 N'oubliez pas que Reed n'est rien, mais qu'il s'agit d'un ensemble de descripteurs de fichiers. 00:54.480 --> 01:00.720 En utilisant la macro FD underscore zero, il s'agit de la macro standard fournie par. 01:01.430 --> 01:08.870 Nous pouvons donc utiliser cette macro pour vider le jeu de lecture. 01:08.900 --> 01:13.040 En d'autres termes, nous initialisons le jeu de descripteurs de fichiers. 01:14.600 --> 01:20.390 Ensuite, nous n'ajoutons que le descripteur de fichier du socket maître à cet ensemble. 01:20.720 --> 01:24.470 La macro à utiliser est donc fd underscore set. 01:24.620 --> 01:30.380 Cette macro ajoutera le descripteur de fichier du socket maître à l'ensemble. 01:31.330 --> 01:31.990 C'est vrai. 01:32.230 --> 01:38.020 À la ligne 91, nous invoquons l'appel système select. 01:39.700 --> 01:40.180 C'est vrai. 01:40.180 --> 01:49.780 Ainsi, au moment où nous atteignons la ligne 91, le jeu de lecture ne contient qu'un seul descripteur de fichier, à savoir le descripteur de 01:49.780 --> 01:52.150 fichier de la socket principale. 01:53.260 --> 01:54.430 En ce moment même. 01:54.430 --> 01:57.190 Examinons le synopsis de l'appel système Select. 01:58.060 --> 02:05.560 Le synopsis de l'appel système Select indique que le premier argument de l'appel système 02:05.560 --> 02:08.350 Select doit être un plus X. 02:10.650 --> 02:21.060 Un plus x, où x est la valeur maximale présente dans l'ensemble des données lues. 02:23.910 --> 02:24.420 C'est vrai. 02:24.420 --> 02:27.510 Il s'agit donc du premier argument de l'appel système select. 02:27.840 --> 02:33.270 Vous pouvez donc voir que dans le jeu de lecture, le seul descripteur de fichier présent est le descripteur de fichier de 02:33.270 --> 02:34.200 la socket maître. 02:34.380 --> 02:37.500 x est donc égal au descripteur de fichier du socket maître. 02:37.770 --> 02:41.940 Le premier argument est donc le descripteur de fichier de la socket principale plus un. 02:42.450 --> 02:45.870 Tel est le résumé de l'appel système de sélection. 02:47.380 --> 02:47.830 C'est vrai. 02:47.830 --> 02:53.310 Les trois arguments suivants de l'appel système select peuvent être passés comme null, null, null. 02:53.350 --> 02:57.520 Il n'est pas nécessaire de discuter des trois autres arguments du système de sélection. 02:57.520 --> 02:59.980 Appel dans ce cours. 03:00.520 --> 03:04.450 Rappelez-vous donc que l'appel système Select est un appel système bloquant. 03:04.960 --> 03:13.810 Au moment où l'appel système select est invoqué, ce processus ou l'exécution de ce programme s'arrête 03:13.840 --> 03:15.160 à la ligne 91. 03:16.000 --> 03:23.080 Vous pouvez constater que le système d'exploitation Linux bloque ce processus jusqu'à ce que les données arrivent sur l'un des descripteurs 03:23.080 --> 03:26.140 de fichiers présents dans l'ensemble de données. 03:26.770 --> 03:32.170 Dans cet exemple, le seul descripteur de fichier présent dans le jeu de lecture est le descripteur de fichier de 03:32.170 --> 03:33.100 la socket maître. 03:34.070 --> 03:40.190 Les descripteurs de fichiers du socket maître sont utilisés pour détecter les nouvelles demandes de connexion émanant de nouveaux clients. 03:40.790 --> 03:48.470 Cela signifie donc que l'appel système select ne surveille que le descripteur de fichier de la socket principale et, comme seul 03:48.470 --> 03:54.800 le descripteur de fichier de la socket principale est surveillé, cela signifie que l'appel système select 03:54.800 --> 04:00.770 est bloqué jusqu'à ce que la nouvelle demande de connexion du client arrive sur ce serveur. 04:02.290 --> 04:02.860 C'est vrai. 04:03.910 --> 04:07.090 Notre serveur est donc bloqué à la ligne 91. 04:08.510 --> 04:15.170 Supposons qu'à un moment donné, un nouveau client envoie une demande d'établissement de connexion 04:15.170 --> 04:17.060 à notre serveur. 04:17.930 --> 04:25.760 Lorsque cela se produit, le processus de notre serveur est débloqué à partir de la ligne 91 et l'exécution 04:25.760 --> 04:27.800 de ce programme reprend. 04:28.460 --> 04:34.370 Ainsi, à la ligne 94, nous vérifions que la macro FD underscore est activée. 04:35.180 --> 04:42.080 Cette macro est donc utilisée pour tester quel descripteur de fichier présent dans le jeu de lecture est activé. 04:42.470 --> 04:47.960 Dans cet exemple, le seul descripteur de fichier possible qui pourrait être activé est le descripteur de fichier 04:47.960 --> 04:48.950 de la socket maître. 04:49.100 --> 04:53.000 Par conséquent, cette condition sera toujours vraie. 04:53.920 --> 04:59.020 Nous aborderons ensuite la mise en œuvre plus complexe du serveur Dhcp. 04:59.560 --> 05:07.630 Dans l'exemple suivant, vous verrez que FD underscore is set est une macro utile et qu'il est nécessaire 05:07.630 --> 05:15.910 de vérifier que l'appel système select est débloqué car quel descripteur de fichier est activé. 05:16.300 --> 05:20.410 Nous devons donc trouver ce descripteur de fichier particulier qui est activé. 05:21.720 --> 05:27.120 Dans cet exemple, il semble évident que nous vérifions le descripteur de fichier de la prise principale 05:27.720 --> 05:33.030 et que nous vérifions si c'est le descripteur de fichier de la prise principale qui est activé. 05:33.810 --> 05:40.470 Et cela semble évident parce que dans le jeu de lecture, le seul descripteur de fichier qui est présent est le descripteur de fichier de la 05:40.470 --> 05:41.250 socket maître. 05:41.730 --> 05:49.560 Quoi qu'il en soit, lorsque cette condition est vraie, cela signifie que notre serveur a reçu de nouvelles demandes de connexion de la part 05:49.560 --> 05:50.910 du nouveau client. 05:52.440 --> 05:55.020 A droite dans ce diagramme. 05:55.020 --> 05:59.980 Nous sommes ici et nous vérifions que le descripteur de fichier de la socket principale est activé. 06:00.030 --> 06:04.600 Donc, dans cet exemple, oui, le descripteur de fichier de la socket principale est activé. 06:04.620 --> 06:11.070 La prochaine chose qu'un serveur doit faire est donc d'établir la connexion avec le client en appelant 06:11.070 --> 06:12.960 l'appel système Accept. 06:15.090 --> 06:15.570 C'est vrai. 06:15.570 --> 06:25.380 Nous en sommes donc à la septième étape : notre serveur invoque l'appel système Accept et, une fois l'appel système Accept 06:25.380 --> 06:31.080 invoqué, la connexion avec le client est censée être établie. 06:31.230 --> 06:37.050 La valeur de retour de l'appel système accept est donc le descripteur de fichier de la socket de communication et c'est à l'aide 06:37.050 --> 06:43.200 de ce descripteur de fichier de la socket de communication que notre serveur effectuera toutes les communications futures avec 06:43.200 --> 06:44.040 le client. 06:44.160 --> 06:50.280 Ce descripteur de fichier de communication représente donc la connexion avec ce client particulier qui 06:50.280 --> 06:52.740 vient de se connecter à notre serveur. 06:53.910 --> 06:57.600 Le deuxième argument de l'appel système accept est le. 06:58.500 --> 06:59.940 Structure vide. 06:59.940 --> 07:03.810 Nous en avons parlé lorsque nous avons abordé le synopsis de l'appel système XRP. 07:04.110 --> 07:11.190 Dès que le client se connecte à notre serveur, cette structure se remplit avec l'adresse 07:11.190 --> 07:14.160 IP et le numéro de port du client. 07:14.880 --> 07:15.540 C'est vrai. 07:15.540 --> 07:20.160 Ainsi, notre serveur sait maintenant avec qui il parle. 07:20.850 --> 07:21.480 C'est vrai. 07:21.480 --> 07:28.680 Notre serveur utilisera donc ces informations pour répondre au client car, en fin de compte, il a besoin 07:28.680 --> 07:34.410 de l'adresse IP du client et du numéro de port pour renvoyer le paquet au client. 07:35.250 --> 07:41.640 Le troisième argument est une constante, qui correspond à la taille de la structure sockaddr. 07:42.360 --> 07:48.080 Ainsi, lorsque l'appel système "accepter" échoue pour une raison quelconque, il renvoie une valeur négative. 07:48.090 --> 07:54.450 Nous vérifions donc simplement que si l'appel système d'acceptation échoue, le processus du serveur 07:54.450 --> 07:55.260 s'arrête. 07:56.900 --> 07:57.560 C'est vrai. 07:57.560 --> 07:58.940 Nous sommes donc ici. 07:58.940 --> 08:04.760 C'est à ce moment-là que le lien avec le client est établi. 08:04.970 --> 08:09.110 Notre processus serveur se contente donc d'imprimer l'identité du client. 08:09.380 --> 08:15.320 Il imprime donc l'adresse IP du client ainsi que le numéro de port du client. 08:15.770 --> 08:23.540 Les API C nous fournissent donc ces fonctions intégrées, à savoir init et to a, qui sont utilisées pour 08:23.540 --> 08:27.230 imprimer l'adresse IP au format dot b dot c dot d. 08:28.150 --> 08:28.660 C'est vrai. 08:28.660 --> 08:33.700 Et nous imprimons le numéro de port du client. 08:34.300 --> 08:39.460 Vous pouvez donc constater que ces étapes sont terminées jusqu'à la septième étape. 08:39.850 --> 08:45.880 En d'autres termes, nous avons invoqué l'appel système select et attendu la demande de connexion 08:45.880 --> 08:50.110 du client, et le serveur a accepté la connexion du client. 08:50.890 --> 08:58.960 La prochaine chose que notre serveur doit faire est d'attendre la demande de données du client, et lorsqu'il reçoit 08:58.960 --> 09:04.780 la demande de données, il traite les données du client et en conséquence il répond 09:04.780 --> 09:07.030 au client avec le résultat. 09:07.730 --> 09:11.060 Voyons donc comment la huitième étape est mise en œuvre. 09:11.720 --> 09:19.010 Le serveur entre à nouveau dans une boucle infinie parce qu'il va parler à ce client indéfiniment 09:19.010 --> 09:25.760 jusqu'à ce que le client envoie des données spéciales au serveur. 09:25.760 --> 09:32.900 En analysant ces données spatiales, notre serveur choisit alors de mettre fin à la connexion avec le client. 09:34.200 --> 09:34.680 C'est vrai. 09:34.680 --> 09:38.250 À ce moment-là, nous sortirons de cette boucle. 09:40.010 --> 09:41.660 Voyons donc cela. 09:41.660 --> 09:41.900 Comment ? 09:41.900 --> 09:44.570 Serveur Échanger les données avec le client. 09:44.960 --> 09:50.210 La première chose que fait le serveur est donc de préparer une mémoire. 09:50.900 --> 09:56.060 Le serveur peut stocker les données envoyées par le client. 09:57.400 --> 09:58.000 C'est vrai. 09:58.000 --> 10:03.790 Une fois que le tampon de données est prêt à se remplir avec les données reçues du serveur, ce dernier 10:03.790 --> 10:06.610 invoque l'appel système "Recevoir de". 10:07.210 --> 10:11.380 La réception de l'appel système est à nouveau un appel système bloquant. 10:12.440 --> 10:17.810 Si vous examinez le synopsis de l'appel système received from, le premier argument de l'appel système receive 10:17.810 --> 10:20.850 from est le descripteur de fichier de communication. 10:20.900 --> 10:26.570 Rappelez-vous donc que toutes les données échangées entre le serveur et le client se produisent sur le descripteur 10:26.570 --> 10:30.920 de fichier de communication et non sur le descripteur de fichier de socket principal. 10:31.340 --> 10:34.340 Le deuxième argument de l'appel système receive from est le. 10:36.410 --> 10:42.680 Tampon de données dans lequel le serveur va stocker les données envoyées par le client. 10:43.010 --> 10:45.560 Le troisième argument est la taille de ce tampon de données. 10:45.590 --> 10:49.040 En d'autres termes, de combien d'octets est constitué ce tampon de données ? 10:49.730 --> 10:52.350 L'argument suivant peut toujours être considéré comme nul. 10:52.370 --> 10:57.380 Nous n'avons pas besoin de discuter de cet argument et. 10:59.330 --> 11:07.010 Le cinquième argument est en fait l'information sur le client que l'appel au système d'acceptation a rempli avec l'information 11:07.010 --> 11:07.940 sur le client. 11:08.360 --> 11:12.880 Le dernier argument est à nouveau la taille de la structure. 11:13.340 --> 11:20.630 Ainsi, lorsque le serveur invoque l'appel système receive from, cela signifie qu'il attend maintenant 11:20.630 --> 11:25.040 la demande de données du client spécifié dans cet argument. 11:26.110 --> 11:26.650 C'est vrai. 11:27.010 --> 11:36.130 Et à moins que le serveur ne reçoive des données de ce client, le serveur restera bloqué sur la réception de l'appel 11:36.130 --> 11:36.940 système. 11:37.750 --> 11:43.150 Il s'agit donc pour l'instant de la ligne 125. 11:43.270 --> 11:48.340 Notre serveur attend maintenant que des données arrivent de ce client. 11:49.840 --> 11:50.620 En ce moment même. 11:50.620 --> 11:54.670 Supposons que le client ait effectivement envoyé des données à notre serveur. 11:55.060 --> 12:01.570 Ainsi, lorsque notre serveur recevra les données de ce client, il sera débloqué de l'appel 12:01.570 --> 12:03.400 système "receive from". 12:04.000 --> 12:09.520 La valeur de retour de l'appel système receive from est le nombre d'octets envoyés par le client. 12:10.580 --> 12:17.030 Ici, nous imprimons simplement le nombre d'octets reçus du client, ainsi que 12:17.030 --> 12:21.080 l'adresse IP du client et le numéro de port. 12:22.100 --> 12:29.060 Ici, nous avons pris comme condition spéciale que si le client nous envoie le nombre zéro d'octets, alors 12:29.060 --> 12:33.870 le serveur considérera que c'est une condition de terminaison. 12:33.890 --> 12:40.240 En d'autres termes, le serveur conclura que le client ne souhaite plus communiquer avec lui. 12:40.250 --> 12:47.930 Le serveur ferme donc la connexion avec ce client particulier et sort de la boucle while 12:47.930 --> 12:48.860 interne. 12:49.520 --> 12:55.790 Mais dans ce cas, supposons que le client ait réellement envoyé des données au serveur. 12:57.170 --> 13:01.850 Les données envoyées au serveur sont donc stockées dans la mémoire tampon. 13:03.310 --> 13:05.230 En ce moment même.