WEBVTT 00:05.000 --> 00:12.020 Avant de plonger dans l'appel système Select and Accept, il est important de discuter de la conception de la communication 00:12.020 --> 00:15.110 de haut niveau basée sur les sockets de Linux. 00:17.980 --> 00:25.930 Pour commencer, les messages envoyés par le client au serveur peuvent être classés en deux catégories. 00:26.920 --> 00:31.900 Le premier type de messages est appelé message de demande d'établissement de connexion. 00:32.890 --> 00:41.170 Ces messages sont utilisés par le client pour demander à un serveur d'établir une connexion spécialisée seulement après que la 00:41.170 --> 00:42.970 connexion a été établie. 00:43.000 --> 00:45.080 Ensuite, seul le client peut envoyer. 00:45.100 --> 00:49.630 Le deuxième type de messages est appelé messages de demande de service. 00:51.770 --> 00:55.790 Le deuxième type de message est donc un message de demande de service. 00:57.110 --> 01:04.340 Le client peut envoyer ce type de messages au serveur une fois que la connexion est entièrement établie par le biais 01:04.340 --> 01:05.540 de ces messages. 01:05.570 --> 01:09.050 Le client demande au serveur de fournir un service. 01:09.800 --> 01:10.370 C'est vrai. 01:10.370 --> 01:14.210 Il existe donc deux types de messages : les messages de connexion, les messages d'initiation et les messages de demande. 01:14.240 --> 01:20.930 Ainsi, lorsque le client C veut se connecter au serveur s, il doit envoyer le message appelé demande 01:20.930 --> 01:23.490 d'initiation de connexion. 01:23.510 --> 01:25.850 Il s'agit donc du premier type de messages. 01:26.720 --> 01:33.590 À l'aide de ces messages, le client demande au serveur d'établir une connexion. 01:35.200 --> 01:41.980 Une fois la connexion établie, seul le client peut utiliser les services du serveur en utilisant un deuxième 01:41.980 --> 01:46.480 type de messages appelés messages de demande de service. 01:49.690 --> 01:55.330 Le serveur identifie et traite donc les deux types de messages de manière très différente. 01:55.360 --> 01:58.570 Nous y reviendrons dans la diapositive suivante. 02:00.750 --> 02:06.600 En résumé, il existe deux types de messages : les messages de demande d'établissement de connexion, qui sont envoyés 02:06.600 --> 02:08.340 par le client au serveur. 02:08.370 --> 02:11.910 Le client envoie ces messages à l'aide d'un appel système "connect". 02:12.030 --> 02:19.410 Connect est donc un appel système Linux qui est utilisé du côté du client, lorsque celui-ci souhaite 02:19.410 --> 02:22.680 établir une connexion avec le serveur. 02:23.100 --> 02:30.150 Le serveur, quant à lui, utilise l'appel système accept pour recevoir la demande d'établissement de la connexion 02:30.150 --> 02:33.480 de la part du client et terminer la connexion. 02:36.620 --> 02:43.730 À cette fin, Linux fournit l'appel système accept, qui doit être utilisé du côté du serveur. 02:44.150 --> 02:47.720 Les autres types de messages sont les messages de demande de service. 02:47.960 --> 02:57.080 Ces messages sont envoyés par le client à l'aide d'API telles que envoyer un message ou envoyer au serveur. 02:57.080 --> 03:04.220 Reçoit les messages de demande de service du client à l'aide de l'API de réception de messages ou de l'API de réception. 03:05.560 --> 03:06.190 C'est vrai. 03:07.510 --> 03:14.380 Vous verrez tous ces appels système en action lorsque nous aborderons la programmation des sockets 03:14.380 --> 03:17.410 en détail plus loin dans ce module. 03:19.960 --> 03:24.820 Essayons maintenant de comprendre le cycle de vie d'une communication client-serveur. 03:26.450 --> 03:33.890 Lorsque le serveur démarre, la toute première chose qu'il fait est de créer un socket principal. 03:34.890 --> 03:40.950 Ce socket maître est créé à l'aide d'un système Linux appelé socket. 03:42.470 --> 03:43.070 C'est vrai. 03:43.250 --> 03:48.410 Nous avons donc ici un serveur et supposons qu'il a démarré. 03:48.410 --> 03:55.340 C'est-à-dire que ce serveur a démarré et que la première chose qu'il va faire est de créer un socket 03:55.340 --> 03:55.940 maître. 03:56.810 --> 04:00.740 Ce socket maître est créé à l'aide de l'appel système socket. 04:01.130 --> 04:03.230 J'utilise maintenant le mot "maître". 04:04.120 --> 04:04.690 C'est vrai. 04:04.690 --> 04:09.800 Cela signifie donc que cette prise a des privilèges particuliers. 04:09.820 --> 04:15.820 Essayons maintenant de comprendre en quoi cette prise est spéciale et quels sont les privilèges qu'elle 04:15.850 --> 04:16.570 possède. 04:18.850 --> 04:23.320 Supposons donc que nous ayons un client C1 quelque part dans le réseau. 04:24.190 --> 04:29.890 Let C1 envoie le message de demande d'établissement de connexion au serveur. 04:30.430 --> 04:34.060 Cela signifie que le client C1 veut se connecter au serveur. 04:35.650 --> 04:42.820 Notez maintenant que le message de demande d'établissement de la connexion est reçu par le serveur sur le socket principal. 04:44.860 --> 04:51.430 Lorsque le serveur reçoit la demande d'initiation de connexion du client à l'aide 04:51.460 --> 04:55.990 du socket principal, il crée un handle pour le client. 04:56.620 --> 05:01.300 Il s'agit donc de la poignée qui est créée par le serveur pour le client. 05:01.350 --> 05:02.020 C1. 05:02.940 --> 05:03.300 Aujourd'hui. 05:03.300 --> 05:04.080 Qu'est-ce qu'une poignée ? 05:04.110 --> 05:08.670 Handle n'est rien, mais c'est un objet qui est créé par le serveur. 05:08.670 --> 05:14.520 C'est à l'aide de cet objet que le serveur effectuera toutes les communications futures avec le client. 05:14.560 --> 05:15.210 C1. 05:15.840 --> 05:22.500 En résumé, le handle n'est rien, mais il représente une connexion du serveur avec le client. 05:22.530 --> 05:23.130 C1. 05:24.150 --> 05:27.450 Supposons maintenant qu'il y ait un autre client C deux. 05:27.960 --> 05:32.610 Il envoie également une nouvelle demande d'établissement de connexion au serveur. 05:33.720 --> 05:39.390 Le serveur transmet la demande d'établissement d'une nouvelle connexion au socket maître. 05:40.470 --> 05:47.490 Après avoir reçu la nouvelle demande d'initiation de connexion à l'aide du socket maître, le serveur crée 05:47.520 --> 05:50.160 un autre handle pour le client C two. 05:50.940 --> 05:51.690 C'est vrai. 05:51.690 --> 05:58.440 Ainsi, chaque fois que le serveur reçoit une nouvelle demande d'initiation de connexion à l'aide de la socket 05:58.440 --> 06:02.100 principale, il crée un nouveau handle pour le client. 06:02.640 --> 06:11.580 C'est pour cette raison que m, c'est-à-dire le socket principal, est la mère de tous les handles clients, c'est-à-dire le socket 06:11.580 --> 06:15.720 principal, qui donne naissance à tous les handles clients. 06:16.370 --> 06:23.240 Ainsi, si deux clients, C1 et C2, sont connectés au serveur, ce dernier disposera 06:23.240 --> 06:25.460 de deux handles clients. 06:26.680 --> 06:34.570 Le serveur doit donc maintenir les deux handles du client en même temps, car il communique désormais avec 06:34.570 --> 06:37.270 les deux clients en même temps. 06:37.870 --> 06:46.240 À ce stade, les clients C1 et C2 ont tous deux établi une connexion complète avec le serveur. 06:46.840 --> 06:53.500 Les clients sont maintenant en mesure d'envoyer des messages de demande de service au serveur. 06:54.040 --> 06:59.620 Supposons donc que le client C2 ait envoyé le message de demande de service au serveur. 07:01.320 --> 07:09.480 Le système d'exploitation qui fonctionne sur le serveur transmet maintenant le message de demande de service directement 07:09.480 --> 07:11.910 à la poignée du client. 07:14.120 --> 07:21.440 Ainsi, le message de demande de service provenant du client C2 sera transmis à la poignée correspondant 07:21.440 --> 07:24.980 au client C2 sur le serveur. 07:27.930 --> 07:34.590 À l'aide de cet identifiant, le serveur traitera la demande du client et lui renverra 07:34.590 --> 07:39.650 la réponse du service à l'aide de l'identifiant C2. 07:40.980 --> 07:41.730 C'est vrai. 07:41.730 --> 07:48.330 Vous pouvez donc voir que la poignée du client sur le serveur est utilisée pour traiter les messages de demande de service 07:48.330 --> 07:49.920 provenant du client. 07:49.920 --> 07:55.980 Après avoir traité le message, la même poignée est utilisée pour renvoyer la réponse du service 07:55.980 --> 07:57.090 au même client. 07:58.900 --> 08:05.500 Ainsi, toutes les communications futures avec le client connecté sont effectuées par la poignée du client, qui a été créée 08:05.500 --> 08:07.630 par le socket maître sur le serveur. 08:09.120 --> 08:15.990 Ainsi, une fois que les numéros de client sont créés pour chaque serveur client, la communication avec le client s'effectue 08:15.990 --> 08:18.750 uniquement à l'aide du numéro de client. 08:19.440 --> 08:25.890 Notez que la socket maître n'est pas impliquée dans le traitement des demandes de service des messages du client. 08:26.630 --> 08:30.440 Les sockets maîtres ne sont pas utilisés pour le service de traitement. 08:30.440 --> 08:32.690 Demander des messages au client. 08:33.930 --> 08:38.210 Le serveur doit maintenir la base de données des clients connectés. 08:38.220 --> 08:43.490 Comme vous pouvez le voir, deux clients sont connectés au serveur en même temps. 08:43.500 --> 08:47.670 Par conséquent, le serveur doit gérer deux clients en même temps. 08:48.240 --> 08:54.630 Ainsi, s'il y a n nombre de clients, le serveur doit maintenir n nombre de gestionnaires de clients afin 08:54.630 --> 08:59.250 de pouvoir communiquer avec chacun d'entre eux de manière indépendante. 09:03.100 --> 09:08.230 Le socket principal n'est utilisé que pour créer de nouveaux handles clients. 09:08.500 --> 09:09.190 C'est vrai. 09:09.190 --> 09:15.190 Vous pouvez voir que le socket maître est utilisé pour traiter uniquement les nouvelles connexions. 09:15.190 --> 09:23.950 Les demandes d'initiation provenant du socket principal du client ne sont pas utilisées pour l'échange de données avec des clients déjà 09:23.950 --> 09:24.730 connectés. 09:24.760 --> 09:28.690 L'échange de données correspond aux messages de demande de service. 09:29.230 --> 09:35.830 Venons-en maintenant à l'appel système accept accept est l'appel système utilisé par le serveur pour créer des 09:35.830 --> 09:37.000 handles clients. 09:37.650 --> 09:45.990 L'appel système accept est donc utilisé par le serveur pour créer de nouveaux handles clients et l'argument de l'appel 09:45.990 --> 09:48.960 système accept est le socket maître. 09:50.270 --> 09:50.780 C'est vrai ? 09:51.230 --> 09:59.480 Dans la terminologie Linux, les handles sont appelés descripteurs de fichiers, qui ne sont rien d'autre que des nombres entiers. 10:00.380 --> 10:01.010 C'est vrai. 10:01.490 --> 10:07.340 Les gestionnaires de clients sont appelés descripteurs de fichiers de communication parce qu'ils sont utilisés pour établir une véritable 10:07.340 --> 10:08.930 communication avec le client. 10:08.960 --> 10:15.680 Il s'agit d'un échange de données, tandis que M est appelé descripteur de fichier de la socket principale. 10:15.680 --> 10:24.050 Ainsi, ce socket M est un maître dans le sens où il est la mère des handles clients. 10:25.250 --> 10:31.220 Pour prendre un exemple, la demande de service pourrait être les deux nombres envoyés par le client 10:31.220 --> 10:35.690 au serveur et le client demande au serveur d'additionner deux nombres. 10:36.680 --> 10:37.540 C'est vrai ? 10:37.550 --> 10:44.870 Lorsque le serveur reçoit ce message du client, il peut additionner les deux nombres et envoyer le résultat. 10:46.260 --> 10:48.010 Retour au client, donc. 10:48.030 --> 10:52.590 Il renverra la somme de A et B au client. 10:52.620 --> 10:55.110 C'est ce qu'on appelle la réponse du service. 10:57.020 --> 11:01.620 C'est ainsi que Linux maintient la communication client-serveur. 11:02.230 --> 11:08.860 L'ensemble de ce tableau décrit donc le cycle de vie d'une communication client-serveur sous Linux.