WEBVTT 00:05.250 --> 00:12.390 Nous allons donc faire un tour de code de notre serveur TCP avec multiplexage pour que vous puissiez voir que nous allons commencer par la fonction 00:12.390 --> 00:18.780 principale et que toute la fonctionnalité du serveur TCP est implémentée à l'intérieur de la fonction de configuration de la communication 00:18.780 --> 00:20.610 du serveur TCP. 00:20.610 --> 00:24.540 Entrons donc dans cette fonction et voyons ce que nous y avons implémenté. 00:26.070 --> 00:26.820 C'est vrai. 00:27.270 --> 00:32.280 Vous connaissez donc déjà la conception et la mise en œuvre d'un serveur TCP. 00:32.280 --> 00:39.120 Je vais donc passer rapidement sur les étapes que nous avons déjà abordées dans la discussion sur la conception 00:39.120 --> 00:41.190 précédente du serveur TCP. 00:41.670 --> 00:46.920 Il s'agit donc de la phase d'initialisation au cours de laquelle nous allons initialiser toutes 00:46.920 --> 00:51.600 les variables que nous devrons utiliser dans la mise en œuvre de ce serveur Dhcp. 00:52.290 --> 00:59.130 Et ici, nous avons pris notre structure de données qui stockera les descripteurs de fichiers de communication de tous 00:59.130 --> 01:01.650 les clients connectés, n'est-ce pas ? 01:01.650 --> 01:07.140 Et pour stocker les informations relatives au serveur et au client, à savoir l'adresse IP et le numéro 01:07.140 --> 01:13.830 de port, nous avons à nouveau pris les deux structures suivantes : ADR underscore serveur et ADR underscore client. 01:14.160 --> 01:14.910 C'est vrai. 01:15.300 --> 01:17.970 Que fait maintenant le serveur TCP ? 01:17.970 --> 01:25.860 La toute première chose que fait ce serveur Dhcp est d'initialiser, de surveiller, de souligner, 01:25.860 --> 01:27.210 de définir. 01:27.480 --> 01:30.390 Voyons donc ce que fait cette fonction. 01:32.250 --> 01:35.220 Vous pouvez donc voir qu'il s'agit de la mise en œuvre de cette fonction. 01:36.400 --> 01:44.020 Cette fonction ne fait donc rien, elle initialise simplement le tableau des descripteurs de fichiers surveillés à moins 01:44.020 --> 01:44.440 un. 01:45.660 --> 01:47.760 Moins un est ici. 01:47.760 --> 01:52.110 Moins un représente l'absence de descripteur de fichier de communication dans ce tableau. 01:52.560 --> 01:59.370 Vous vous souvenez que lorsque nous avons discuté de la conception de haut niveau, notre serveur TCP maintenait ce 01:59.370 --> 02:00.270 tableau, qui. 02:01.610 --> 02:07.210 qui a été utilisé pour stocker le descripteur de fichier de communication ainsi que le descripteur de fichier de socket maître. 02:07.220 --> 02:10.730 C'est donc de ce tableau qu'il est question ici. 02:10.760 --> 02:12.820 Ce tableau est appelé. 02:12.830 --> 02:17.000 Appelons donc ce tableau "ensemble de descripteurs de fichiers surveillés". 02:17.390 --> 02:23.330 Nous avons donc initialisé ce tableau avec moins un, ce qui signifie qu'à ce stade, le serveur 02:23.330 --> 02:26.990 n'a pas de descripteur de fichier à surveiller. 02:27.890 --> 02:28.520 C'est vrai. 02:28.520 --> 02:31.970 Nous venons donc d'initialiser ce tableau dans cette fonction. 02:34.380 --> 02:35.210 C'est vrai. 02:35.220 --> 02:41.610 La deuxième chose que fait le serveur Dhcp est de créer un descripteur de fichier de socket principal, n'est-ce pas ? 02:41.640 --> 02:43.460 Nous en avons déjà parlé. 02:43.470 --> 02:51.320 Le serveur TCP utilise ensuite la structure server underscore addr pour spécifier ses propres informations d'identification. 02:51.330 --> 02:56.220 Il s'agit de son numéro de port TCP et de son adresse IP. 03:00.110 --> 03:07.130 Dans un troisième temps, le serveur TCP appelle l'appel système bind, qui lui permet de communiquer au système 03:07.130 --> 03:13.220 d'exploitation sous-jacent le type de paquet ou de serveur TCP qui l'intéresse. 03:13.250 --> 03:20.570 Notre serveur TCP souhaite donc recevoir un paquet dont le numéro de port de destination dans l'en-tête 03:20.600 --> 03:24.230 de transport est égal au numéro de port du serveur. 03:25.380 --> 03:33.330 L'adresse IP spécifiée dans l'en-tête du paquet est égale à l'adresse IP de n'importe quelle interface locale de 03:33.330 --> 03:35.160 cette machine serveur. 03:37.410 --> 03:37.890 C'est vrai. 03:37.890 --> 03:42.660 Ces étapes ne sont donc pas différentes de celles dont nous avons discuté dans le. 03:43.380 --> 03:45.750 Discussion sur le serveur TCP précédent. 03:45.780 --> 03:47.370 Ce sont exactement les mêmes. 03:47.490 --> 03:49.890 Ensuite, il y a un appel au système de leçons. 03:51.120 --> 03:51.720 C'est vrai. 03:51.720 --> 03:59.130 À ce stade, c'est-à-dire à la ligne 136, le serveur TCP a créé un descripteur de fichier, appelé descripteur 03:59.130 --> 04:01.830 de fichier de la socket principale. 04:02.280 --> 04:08.760 Ainsi, dès que notre serveur crée un nouveau descripteur de fichier, qu'il s'agisse d'un descripteur de fichier de la socket 04:08.760 --> 04:15.280 principale ou d'un descripteur de fichier de communication, il doit ajouter ce descripteur de fichier à ce tableau. 04:16.590 --> 04:17.280 C'est vrai. 04:18.000 --> 04:24.420 Nous avons donc appelé cette fonction add to monitor file descriptor set et nous avons passé le descripteur de fichier que le serveur 04:24.420 --> 04:28.430 a créé, c'est-à-dire le descripteur de fichier de la socket principale. 04:28.440 --> 04:33.540 Cette fonction permet donc d'ajouter le descripteur de fichier de la socket maître au tableau. 04:35.590 --> 04:38.560 Entrons donc dans cette fonction et voyons ce qu'il en est. 04:41.760 --> 04:46.680 Vous pouvez donc constater que la mise en œuvre de cette fonction est relativement, très simple. 04:46.800 --> 04:53.670 Nous itérons sur le tableau et dès que nous trouvons un emplacement vide dans le tableau, qui est représenté 04:53.670 --> 05:03.030 par la valeur moins un dans cet emplacement particulier, nous ajoutons le descripteur de fichier qui doit être surveillé à ce tableau. 05:03.910 --> 05:04.390 C'est vrai. 05:04.390 --> 05:06.070 La mise en œuvre est donc simple. 05:09.220 --> 05:15.850 Ainsi, avant d'entrer dans la boucle while one, notre serveur TCP a démarré et a créé un descripteur de fichier 05:15.850 --> 05:21.840 de socket principal et a ajouté le descripteur de fichier de socket principal à ce tableau. 05:22.980 --> 05:31.440 Vous pouvez donc voir ici que notre serveur TCP est ici et qu'il est sur le point d'entrer dans la boucle while pour faire un appel à l'appel système 05:31.440 --> 05:37.140 select afin qu'il puisse surveiller le descripteur de fichier qu'il est censé surveiller. 05:37.170 --> 05:44.100 Vous pouvez donc voir que dès que le serveur entre dans la boucle infinie, il ré-initie la lecture de l'ensemble des données. 05:44.400 --> 05:45.990 Que fait cette fonction ? 05:45.990 --> 05:47.550 Cette fonction ne fait rien. 05:47.550 --> 05:57.270 Il crée simplement un clone ou une copie de ce tableau de descripteurs de fichiers surveillés et il copie ce tableau dans le jeu de lecture 05:57.270 --> 06:03.600 parce qu'en fin de compte, pour le système de sélection, la structure de données que vous 06:03.600 --> 06:06.240 devez passer est le jeu de lecture. 06:06.990 --> 06:16.080 Ainsi, votre jeu de lecture doit être exactement le clone ou la copie de votre tableau de descripteurs de fichiers surveillés. 06:17.890 --> 06:22.150 C'est donc la fonction re init read set qui fait ce travail. 06:22.630 --> 06:27.130 Voyons donc la mise en œuvre de cette fonction : que fait-elle ? 06:27.160 --> 06:33.670 Cette fonction ne fait donc rien d'autre que de vider le jeu rouge que vous lui avez passé en 06:33.670 --> 06:40.450 argument, puis de parcourir le tableau des jeux de descripteurs de fichiers surveillés. 06:40.720 --> 06:41.470 C'est vrai ? 06:41.470 --> 06:49.480 Et pour tous les descripteurs de fichiers présents dans ce tableau, il suffit de copier tous ces descripteurs de 06:49.480 --> 06:52.300 fichiers du tableau vers le jeu rouge. 06:52.330 --> 06:59.890 Cette fonction crée donc une copie ou un clone de l'ensemble de descripteurs de fichiers surveillés dans 06:59.890 --> 07:01.510 l'ensemble rouge. 07:03.920 --> 07:10.820 En effet, le tableau des descripteurs de fichiers surveillés contient tous les descripteurs de fichiers surveillés 07:10.820 --> 07:13.430 à tout moment par notre serveur TCP. 07:13.430 --> 07:18.190 Ces descripteurs de fichiers doivent également être présents dans l'ensemble. 07:20.690 --> 07:21.290 C'est vrai. 07:21.290 --> 07:27.320 Ainsi, après avoir copié et rempli l'ensemble de lecture avec les descripteurs de fichiers requis. 07:27.350 --> 07:32.810 Il est maintenant temps pour notre serveur TCP de lancer l'appel système select. 07:34.240 --> 07:39.730 Vous pouvez donc voir que l'appel système select a été appelé sur le jeu de lecture, qui contient tous les descripteurs 07:39.730 --> 07:41.350 de fichiers à surveiller. 07:43.390 --> 07:50.200 Mais à ce stade, notre serveur TCP n'a qu'un seul descripteur de fichier dans ce jeu de lecture, qui est le descripteur de fichier 07:50.200 --> 07:56.470 de la socket principale, et il n'a pas de descripteur de fichier de communication pour l'instant parce qu'aucun 07:56.470 --> 07:59.740 client ne s'est encore connecté à notre serveur TCP. 08:01.660 --> 08:08.680 Vous pouvez donc voir dans ce diagramme qu'un serveur TCP a invoqué l'appel système select sur l'ensemble et que notre serveur TCP est 08:08.680 --> 08:14.260 maintenant bloqué dans l'attente d'une demande d'établissement de connexion de la part d'un client. 08:16.060 --> 08:17.890 En ce moment même. 08:17.890 --> 08:25.600 Supposons qu'un client C1 vienne envoyer une demande d'établissement de connexion à notre serveur TCP. 08:26.870 --> 08:33.760 Ainsi, lorsque cela se produit, notre serveur Dhcp est débloqué de l'appel système select et dans le jeu de lecture, le descripteur 08:34.160 --> 08:37.610 de fichier de la socket principale est activé. 08:39.050 --> 08:39.500 C'est vrai. 08:39.500 --> 08:45.380 Nous allons donc vérifier ici que le descripteur de fichier du socket maître est activé dans le jeu de lecture. 08:45.410 --> 08:52.550 Cela signifie que notre serveur a reçu une nouvelle demande de connexion de la part d'un client et qu'il est temps pour notre serveur 08:52.550 --> 08:59.210 d'accepter la connexion et de créer le descripteur de fichier de communication pour ce client particulier. 09:01.410 --> 09:08.580 Vous pouvez donc voir dans ce diagramme que le client C1 envoie la demande d'initiation de connexion au serveur TCP ou que 09:08.730 --> 09:14.910 le serveur TCP invoque l'appel système Accept et crée le descripteur de fichier de communication. 09:15.240 --> 09:21.690 Grâce à ce descripteur de fichier de communication ou au serveur TCP, toutes les communications futures avec le client 09:21.690 --> 09:23.100 C1 seront effectuées. 09:24.660 --> 09:25.890 En ce moment même. 09:25.890 --> 09:32.100 Comme je l'ai expliqué, la conception de haut niveau prévoit que, quel que soit le descripteur de fichier de communication ou le serveur 09:32.100 --> 09:38.640 TCP créé, il doit stocker ce descripteur de fichier de communication dans le tableau de l'ensemble des descripteurs de fichiers surveillés. 09:39.060 --> 09:39.720 C'est vrai. 09:39.720 --> 09:47.160 Il est donc temps d'invoquer cette fonction qui va ajouter au tableau le descripteur de fichier de communication 09:47.160 --> 09:51.570 du client qui vient de se connecter à notre serveur TCP. 09:54.210 --> 09:54.810 C'est vrai. 09:54.810 --> 09:57.950 Nous avons déjà discuté de la mise en œuvre de cette fonction. 09:57.960 --> 10:03.990 Elle ajoute simplement le descripteur de fichier, qui est transmis en tant qu'argument à cette fonction, 10:04.020 --> 10:06.210 dans l'emplacement vide du tableau. 10:08.710 --> 10:09.340 C'est vrai. 10:09.340 --> 10:16.900 À ce stade, le client C1 vient de se connecter à notre serveur TCP et notre serveur TCP a créé le descripteur de 10:16.900 --> 10:19.950 fichier de communication pour ce client. 10:19.960 --> 10:26.590 Et comme je l'ai dit, notre serveur TCP utilisera ce descripteur de fichier de communication pour effectuer tous les échanges 10:26.590 --> 10:28.300 de données avec ce client. 10:28.330 --> 10:37.120 C1 D'accord, et ce descripteur de fichier de communication a été ajouté au tableau, n'est-ce pas ? 10:37.420 --> 10:41.440 Vous pouvez donc le voir dans l'ensemble des données lues à ce stade. 10:42.270 --> 10:45.000 Le descripteur de fichier de la socket principale était déjà présent. 10:45.030 --> 10:48.060 Le descripteur de fichier de communication est maintenant également présent. 10:48.840 --> 10:49.470 C'est vrai. 10:49.470 --> 10:54.510 Rappelez-vous donc que nous ajoutons le descripteur de fichier de communication au tableau et au début 10:54.510 --> 10:55.800 de la boucle while one. 10:56.750 --> 11:01.880 Nous avons copié l'ensemble du tableau sur l'ensemble FDR, de sorte qu'il est aussi bon que vous. 11:01.880 --> 11:05.090 Ajout du descripteur de fichier de communication à l'ensemble FDR. 11:05.660 --> 11:06.350 C'est vrai. 11:08.090 --> 11:13.340 Jusqu'à présent, nous avons vu que le client C1 vient d'arriver et qu'il est connecté à notre serveur. 11:13.370 --> 11:18.770 Notre serveur a créé le descripteur de fichier de communication pour ce client et notre serveur a ajouté ce descripteur 11:18.770 --> 11:21.440 de fichier de communication à l'ensemble FDR. 11:24.490 --> 11:26.860 Par conséquent, l'autre partie ne fonctionnera pas. 11:27.970 --> 11:35.320 Ensuite, nous passerons à la boucle unique, c'est-à-dire que notre serveur retournera maintenant à la boucle while one. 11:35.920 --> 11:44.440 Ainsi, notre serveur réintègre ou réitère la boucle infinie qu'est la boucle while one et appelle le jeu de lecture re init 11:44.770 --> 11:46.030 qui se trouve ici. 11:46.030 --> 11:48.760 Il doit rafraîchir l'ensemble des données lues. 11:49.150 --> 11:55.150 Rappelez-vous que lors de l'itération précédente, le jeu de lecture ne contenait que le descripteur de fichier de la socket principale. 11:55.420 --> 12:02.320 Et maintenant, parce que notre serveur a établi la connexion avec le nouveau client, notre serveur a maintenant deux descripteurs 12:02.320 --> 12:04.570 de fichiers à surveiller. 12:04.780 --> 12:09.760 Le premier est le descripteur de fichier de la socket principale et le second est le descripteur de fichier 12:09.760 --> 12:11.560 de communication du client c one. 12:11.860 --> 12:21.340 Ainsi, le re init read prendra soin de recopier le nouvel ensemble de descripteurs de fichiers à surveiller et à lire correctement, 12:21.700 --> 12:28.040 puis notre serveur se bloque à nouveau au niveau de l'appel système select. 12:28.040 --> 12:35.030 À ce stade, notre serveur surveille la nouvelle demande de données émanant du client C 1, qui est déjà connecté 12:35.030 --> 12:42.680 à notre serveur, et notre serveur est également en mesure de traiter les nouvelles demandes d'établissement de connexion 12:42.680 --> 12:45.080 émanant de nouveaux clients. 12:45.470 --> 12:46.010 Pourquoi ? 12:46.040 --> 12:52.370 Parce qu'il surveille le descripteur de fichier du socket maître ainsi que le descripteur de fichier de communication du client 12:52.400 --> 12:53.030 C one. 12:55.020 --> 13:01.080 Ainsi, la même chose se répète : notre serveur TCP est débloqué de l'appel système select. 13:01.080 --> 13:09.810 Si le client C1 envoie une demande de données au serveur TCP ou si le client C2 envoie une demande d'initiation de connexion 13:09.810 --> 13:16.830 à notre serveur TCP, ce dernier est débloqué si l'un de ces deux événements se produit. 13:18.280 --> 13:25.000 Vous pouvez donc voir ici que si la demande d'établissement d'une nouvelle connexion provient du client C2, cette 13:25.000 --> 13:26.410 condition sera vraie. 13:27.390 --> 13:31.620 Oui, parce que c'est le descripteur de fichier de la socket principale qui sera activé. 13:32.340 --> 13:33.030 C'est vrai. 13:33.510 --> 13:40.410 Et si de nouvelles demandes de données arrivent du client C1 qui est déjà connecté à notre serveur, alors la partie 13:40.410 --> 13:41.730 "else" s'exécutera. 13:42.330 --> 13:44.100 Oui, parce que. 13:45.620 --> 13:50.390 Tout descripteur de fichier autre que le descripteur de fichier du socket maître sera activé. 13:51.590 --> 13:52.220 C'est vrai. 13:52.220 --> 14:00.140 Ainsi, lorsque cette partie est activée, nous devons déterminer quel descripteur de fichier de communication 14:00.140 --> 14:07.250 est activé, car de nombreux clients peuvent être connectés au serveur à un moment donné. 14:07.820 --> 14:16.550 Pour ce faire, nous devons parcourir le tableau des descripteurs de fichiers surveillés et vérifier lesquels. 14:17.360 --> 14:24.500 Le client a envoyé la demande de données à notre serveur, nous pouvons donc le faire en itérant sur le tableau. 14:24.530 --> 14:33.890 Surveiller le tableau de l'ensemble des descripteurs de fichiers et vérifier si un trait de soulignement macro est défini et si ce descripteur de 14:33.890 --> 14:37.940 fichier particulier a été activé dans l'ensemble de lecture. 14:39.480 --> 14:40.080 C'est vrai. 14:40.080 --> 14:46.950 Ainsi, la condition "if" ne sera vraie que pour les descripteurs de fichiers de communication qui sont activés dans 14:46.950 --> 14:48.150 le jeu de lecture. 14:51.510 --> 14:52.530 En ce moment même. 14:52.530 --> 14:59.280 La prochaine chose que le serveur TCP doit faire est de recevoir les données du client dont le descripteur 14:59.280 --> 15:03.540 de fichier de communication est activé et de renvoyer la réponse. 15:04.510 --> 15:10.040 Il s'agit donc à nouveau de la même logique que celle que vous avez déjà apprise dans le serveur TCP précédent. 15:10.060 --> 15:11.610 Préparer le tampon de données. 15:11.620 --> 15:13.510 Recevoir les données du client. 15:14.620 --> 15:15.190 C'est vrai. 15:17.130 --> 15:23.940 Et si le client suppose que le client a envoyé zéro octet de données à un serveur TCP, alors notre serveur TCP peut fermer 15:23.970 --> 15:25.920 la connexion avec ce client. 15:25.920 --> 15:32.670 Dès que notre serveur TCP ferme la connexion avec ce client, il n'a plus besoin de surveiller ce descripteur 15:32.670 --> 15:39.050 de fichier de communication lors des prochaines invocations d'appels système sélectionnés. 15:39.060 --> 15:44.370 C'est la raison pour laquelle nous devons supprimer ce descripteur de fichier de communication de notre tableau de descripteurs 15:44.370 --> 15:45.810 de fichiers surveillés. 15:49.360 --> 15:57.490 Dans le cas contraire, si le client a envoyé des données légitimes à notre serveur TCP pour qu'il les traite, notre serveur 15:57.490 --> 16:00.560 TCP les intégrera dans les données du client. 16:00.580 --> 16:02.170 C'est-à-dire notre serveur TCP. 16:02.170 --> 16:05.740 Il doit savoir dans quel format le client a envoyé les données. 16:08.500 --> 16:09.100 C'est vrai. 16:09.100 --> 16:16.240 Notre serveur TCP additionne simplement les valeurs envoyées par le client, calcule la somme des 16:16.240 --> 16:19.720 deux valeurs et renvoie la réponse au client. 16:20.440 --> 16:27.100 Il s'agit donc de la même logique que celle qui consiste à recevoir la demande du client, à la traiter et à renvoyer 16:27.100 --> 16:29.080 le résultat au client. 16:31.250 --> 16:35.780 Vous pouvez donc voir que toute cette logique se trouve à l'intérieur de cette boucle for. 16:36.260 --> 16:46.250 En d'autres termes, nous vérifions tous les descripteurs de fichiers de communication activés dans l'ensemble et tous les descripteurs de fichiers 16:46.250 --> 16:48.590 de communication activés. 16:48.860 --> 16:56.900 Cela signifie que plusieurs clients ont envoyé des données à notre serveur TCP ou que le serveur TCP traite une à 16:56.900 --> 17:01.580 une les demandes de données de ces clients et renvoie la réponse. 17:03.230 --> 17:09.740 C'est donc toute la logique du multiplexage qui est mise en œuvre dans la partie "else". 17:12.770 --> 17:18.530 Ainsi, en avançant dans ce diagramme, vous pouvez voir si le client C2 a envoyé la demande d'initiation de connexion 17:18.530 --> 17:20.210 à notre serveur TCP. 17:20.330 --> 17:22.580 Notre serveur TCP accepte la connexion. 17:22.580 --> 17:27.800 Nous allons créer un autre descripteur de fichier de communication et nous allons ajouter ce descripteur 17:27.800 --> 17:36.500 de fichier de communication à l'ensemble et il utilisera le descripteur de fichier de communication respectif afin d'effectuer l'échange de données avec les 17:36.500 --> 17:38.720 clients correspondants. 17:40.400 --> 17:45.500 Voici donc le diagramme d'état complet d'un serveur TCP avec multiplexage. 17:45.500 --> 17:52.070 Ce diagramme illustre le fonctionnement d'un serveur TCP doté de capacités de multiplexage. 17:53.780 --> 18:00.440 Vous pouvez donc vous aider de ce code et je vous demande d'écrire votre propre serveur TCP avec multiplexage. 18:00.440 --> 18:02.620 Cela vous donnera une bonne pratique. 18:02.630 --> 18:09.710 Ne vous contentez pas de regarder ce code, sinon vous ne vous sentirez pas à l'aise pour écrire un serveur TCP ou pour programmer 18:09.710 --> 18:11.240 des sockets. 18:14.020 --> 18:16.870 Et téléchargez tous vos codes sur GitHub. 18:16.900 --> 18:22.090 Bien entendu, je partagerai avec vous les chemins d'accès à tous ces codes dans la section des ressources. 18:22.570 --> 18:25.480 Il s'agissait donc d'un serveur Dhcp avec multiplexage. 18:25.870 --> 18:32.770 Ensuite, nous verrons la démonstration du serveur Dhcp avec le multiplexage et nous verrons comment le serveur Dhcp peut 18:32.770 --> 18:35.770 communiquer avec plusieurs clients en même temps.