WEBVTT 00:05.730 --> 00:08.310 Il s'agit donc d'un module très court. 00:08.310 --> 00:14.880 Dans ce module, nous allons apprendre le concept de multiplexage et nous verrons comment le multiplexage 00:14.880 --> 00:22.890 peut être appliqué à un processus grâce auquel le processus peut recevoir les données de plusieurs mécanismes IPC en même 00:22.890 --> 00:24.120 temps. 00:25.300 --> 00:30.220 Nous avons donc étudié le multiplexage dans le contexte des sockets de domaine Unix. 00:30.370 --> 00:36.940 Si vous vous souvenez de l'étude du multiplexage dans le contexte des sockets de domaine Unix, notre processus 00:36.940 --> 00:42.580 serveur pouvait en fait lire les données envoyées par n'importe quel client connecté. 00:42.610 --> 00:49.540 Le multiplexage a donc aidé notre serveur à traiter simultanément les données qui pouvaient être reçues à tout 00:49.540 --> 00:52.630 moment de n'importe quel client connecté. 00:53.310 --> 00:59.250 Nous allons maintenant appliquer le concept de multiplexage au niveau de l'IPC. 00:59.280 --> 01:08.160 C'est-à-dire que nous avons un processus serveur et que ce processus serveur peut recevoir des données de manière asynchrone à partir 01:08.160 --> 01:10.830 d'un socket réseau Unix domain socket. 01:10.950 --> 01:18.060 Il peut recevoir les données de la console, c'est-à-dire de l'utilisateur, et il peut recevoir les données de la file d'attente 01:18.060 --> 01:18.960 des messages. 01:19.170 --> 01:27.120 Vous pouvez donc voir que notre processus serveur a ouvert une file d'attente de messages de socket réseau de domaine 01:27.120 --> 01:29.070 Unix ainsi qu'une console. 01:29.070 --> 01:36.180 Et à partir de n'importe lequel de ces canaux, notre processus serveur peut effectivement recevoir des données à tout moment. 01:36.660 --> 01:39.810 À tout moment signifie de manière asynchrone. 01:39.840 --> 01:48.030 La question est donc de savoir comment concevoir un processus qui récupère les données envoyées par n'importe 01:48.030 --> 01:50.820 quel mécanisme IPC et les traite. 01:51.780 --> 01:54.240 Voyons donc comment procéder. 01:54.930 --> 02:00.540 Vous pouvez donc voir dans ce diagramme que nous avons un processus serveur et que ce processus serveur 02:00.540 --> 02:09.390 peut recevoir les données de n'importe quel client de domaine Unix ou de n'importe quel client réseau qui est un client TCP ou UDP ou de n'importe quel client 02:09.390 --> 02:11.450 qui communique sur le réseau. 02:11.460 --> 02:16.020 Notre processus serveur peut également recevoir les données des files d'attente de messages. 02:17.040 --> 02:23.550 Notez qu'il peut y avoir plus d'un message parce qu'il peut y avoir plus d'un client 02:23.550 --> 02:27.450 réseau et plus d'un client de domaine Unix. 02:27.870 --> 02:34.200 Le processus serveur va donc récupérer les données envoyées par n'importe quel client, qu'il s'agisse 02:34.200 --> 02:39.900 d'un client socket de domaine Unix ou d'un client socket de domaine réseau, ou encore d'un 02:39.900 --> 02:45.930 client qui tourne sur la même machine et qui envoie les données à notre processus serveur à l'aide 02:45.930 --> 02:48.570 de files d'attente de messages. 02:49.230 --> 02:51.360 Passons donc en revue ces points. 02:51.390 --> 02:58.050 Si vous remarquez que les sockets réseau, les sockets de domaine Unix et les files d'attente de messages ont des descripteurs de fichiers. 02:58.380 --> 03:05.280 Nous savons déjà que lorsque vous créez une socket Unix, une socket réseau ou une file d'attente de messages, 03:05.430 --> 03:08.640 l'API renvoie le descripteur de fichier. 03:08.640 --> 03:13.410 Ce descripteur de fichier est donc en fait la représentation d'un socket, n'est-ce pas ? 03:13.410 --> 03:18.120 Nous avons déjà appris le multiplexage dans le contexte des sockets dans le module 1. 03:18.780 --> 03:27.000 Dans ce cas, il suffit donc d'ajouter tous les descripteurs de fichiers à la structure de données set et d'invoquer l'appel 03:27.000 --> 03:29.040 système select sur ce set. 03:29.250 --> 03:35.970 Ce faisant, notre processus serveur va effectuer un multiplexage sur tous les descripteurs de fichiers présents dans la structure 03:35.970 --> 03:37.710 de données de l'ensemble. 03:38.370 --> 03:46.650 Ainsi, l'appel système select se débloquera si le serveur reçoit des données sur un descripteur de fichier par le biais d'un mécanisme IPC. 03:46.650 --> 03:48.840 Le concept est donc le même. 03:50.000 --> 03:56.960 Le contenu du descripteur de fichier doit donc indiquer qu'il doit contenir des données sur les sockets des clients du réseau. 03:57.020 --> 04:04.070 Il s'agit des descripteurs de fichiers de communication de tous les clients du réseau, plus le descripteur de fichiers du socket principal 04:04.070 --> 04:05.570 du socket du réseau. 04:05.930 --> 04:06.650 C'est vrai. 04:06.680 --> 04:13.250 Il doit également disposer des sockets de données de tous les clients du domaine Unix et du socket maître du 04:13.280 --> 04:17.270 socket du domaine Unix, que nous appelons socket de connexion. 04:17.420 --> 04:18.260 C'est vrai. 04:18.590 --> 04:24.800 En outre, les descripteurs de fichiers de toutes les files d'attente de messages à partir desquelles notre processus 04:24.800 --> 04:26.930 serveur souhaite lire les messages. 04:27.140 --> 04:28.000 C'est vrai. 04:28.010 --> 04:34.460 La dernière chose que vous pouvez ajouter à cette structure de données est la valeur zéro, qui représente en fait 04:34.490 --> 04:35.450 une console. 04:36.410 --> 04:43.400 L'ajout d'un descripteur de fichier zéro à l'ensemble permet à notre processus serveur d'écouter la console. 04:44.030 --> 04:51.530 Cela permettra donc à l'utilisateur ou à l'administrateur d'interagir avec le processus du serveur pendant que ce dernier est bloqué 04:51.530 --> 04:58.970 par l'appel système de sélection parce que zéro en tant que descripteur de fichier a été ajouté à l'ensemble, la structure de données 04:59.270 --> 05:04.940 et la structure de données de l'ensemble sont surveillées par l'appel système de sélection. 05:07.190 --> 05:15.020 Vous pouvez donc voir que si vous ajoutez tous ces descripteurs de fichiers à la structure de données set et que vous invoquez 05:15.020 --> 05:23.750 select system, call sur cette structure de données set, notre processus serveur va surveiller toutes les interfaces IPC qu'il a ouvertes 05:23.750 --> 05:31.310 afin d'interagir avec d'autres processus s'exécutant sur le même système ou sur un système différent. 05:31.970 --> 05:34.060 Le concept est donc simple. 05:34.070 --> 05:37.550 Nous pouvons invoquer le système de sélection, faire appel à des descripteurs de fichiers. 05:37.580 --> 05:43.100 Peu importe que le descripteur de fichier appartienne au domaine Unix sockets ou network socket 05:43.100 --> 05:44.810 ou message queue ou autre. 05:44.840 --> 05:49.040 L'appel système select fonctionne avec tous les types de descripteurs de fichiers. 05:49.370 --> 05:53.420 C'était donc le concept du multiplexage et de l'utilisation du multiplexage. 05:53.420 --> 06:00.080 Vous pouvez concevoir votre processus serveur de manière à ce qu'il puisse lire simultanément les données provenant de divers 06:00.080 --> 06:00.980 mécanismes IPC.