WEBVTT 00:05.580 --> 00:12.030 Nous allons donc discuter du projet sur le socket de domaine Unix et le nom du projet est Synchronisation 00:12.030 --> 00:13.710 des données. 00:13.830 --> 00:21.750 Nous allons donc voir comment la communication inter-processus peut être utilisée pour réaliser la synchronisation des données entre les processus 00:21.750 --> 00:23.790 s'exécutant sur la même machine. 00:24.900 --> 00:29.820 Dans ce projet, nous allons donc créer un processus de gestion de la table de routage. 00:29.820 --> 00:37.380 Il s'agit donc d'un processus spécial appelé processus de gestion de la table de routage, abrégé en RTM. 00:37.890 --> 00:45.180 Un gestionnaire de table de routage est en fait responsable d'une table de routage de 00:45.180 --> 00:47.670 la couche 3, n'est-ce pas ? 00:47.730 --> 00:55.530 Il incombe à ce processus de maintenir la table de routage L3 et d'envoyer une notification de tout changement 00:55.530 --> 00:57.840 dans cette table de routage. 00:57.840 --> 01:00.150 Contenu aux clients connectés. 01:01.680 --> 01:07.950 L'état de la table de routage doit être synchronisé entre tous les clients à tout moment. 01:07.950 --> 01:11.040 Tel est donc l'objectif de ce projet. 01:11.730 --> 01:20.400 L'objectif final de ce projet est que l'état de la table de routage soit exactement le même pour tous les clients 01:20.400 --> 01:22.080 connectés. 01:22.200 --> 01:25.650 Essayons donc de comprendre ce projet un peu plus en détail. 01:26.280 --> 01:30.120 Quelle est donc la vision d'ensemble de ce projet ? 01:30.150 --> 01:37.140 Vous disposez donc d'un processus spécial que nous appelons RTM, c'est-à-dire processus de gestion de la table de routage. 01:37.290 --> 01:43.260 Et comme je l'ai dit, ce processus est en fait responsable d'une table de routage. 01:43.790 --> 01:45.590 En ce moment même. 01:45.590 --> 01:48.950 D'autres processus sont également en cours d'exécution dans le système. 01:48.980 --> 01:55.730 Ces processus sont appelés processus clients, et ces clients sont connectés à notre processus de gestion des tables 01:55.730 --> 01:58.910 de routage en tant que clients de domaine Unix. 01:59.180 --> 02:07.940 Notre processus est donc en fait un processus serveur et les autres processus sont des processus clients qui sont 02:07.940 --> 02:13.760 connectés à notre processus RTM à l'aide de sockets de domaine Unix. 02:15.220 --> 02:24.850 Désormais, chaque fois qu'une entrée est ajoutée, supprimée ou créée dans une table de routage gérée par le 02:24.850 --> 02:33.160 processus RTM, il incombe à ce dernier de synchroniser la même opération avec tous les clients 02:33.160 --> 02:34.570 connectés. 02:35.200 --> 02:40.090 Ces opérations sont donc abrégées en opérations CD. 02:40.120 --> 02:41.710 C est l'abréviation de Créer. 02:41.740 --> 02:44.800 U est l'abréviation de "Update" (mise à jour) et D est l'abréviation de "Delete" (suppression). 02:45.520 --> 02:46.180 C'est vrai. 02:46.900 --> 02:55.180 Le processus de gestion de la table de routage (RTM) envoie donc une mise à jour en file d'attente sur notification à tous les clients connectés. 02:55.390 --> 03:01.300 Bien, discutons donc de ce projet un peu plus en détail et étape par étape. 03:01.870 --> 03:05.440 Le RTM est donc en fait un responsable de la table de routage. 03:05.890 --> 03:08.410 Ce tableau est géré par l'administrateur. 03:08.410 --> 03:10.270 Alors, qui est l'administrateur ? 03:10.270 --> 03:15.460 L'administrateur est une personne qui interagit réellement avec le processus RTM. 03:15.580 --> 03:22.870 Cet administrateur peut choisir de créer, de mettre à jour ou de supprimer n'importe quelle entrée de la table de routage 03:22.870 --> 03:24.880 gérée par le processus RTM. 03:24.910 --> 03:28.780 Un exemple de ce type de tableau est présenté ci-dessous. 03:29.350 --> 03:33.490 Voici donc un exemple de table de routage très simple. 03:34.270 --> 03:36.640 Il se compose de trois champs. 03:36.670 --> 03:42.280 Le premier champ, appelé sous-réseau de destination, contient une adresse IP dans ce format. 03:43.130 --> 03:48.650 Le deuxième champ est l'IP de la passerelle, et le troisième champ est en fait un nom d'interface. 03:48.680 --> 03:54.590 Il n'est pas nécessaire de comprendre ce que signifie exactement cette entrée dans une table de routage. 03:54.620 --> 04:00.920 Il suffit de comprendre qu'il existe une table composée de trois champs, à savoir l'adresse 04:00.920 --> 04:08.210 IP de destination, le sous-réseau, l'adresse IP de la passerelle et l'interface de sortie. 04:09.600 --> 04:12.060 Il s'agit d'un projet approprié. 04:12.060 --> 04:18.450 Vous pouvez également choisir de travailler avec un autre type de table, celui avec lequel vous vous sentez le plus à l'aise. 04:18.480 --> 04:21.870 Pour cet exemple, je l'ai pris comme table de routage. 04:24.460 --> 04:30.910 Pour construire la table de routage sur le processus RTM, vous êtes libre de choisir n'importe quelle structure de données pour représenter 04:30.910 --> 04:32.750 cette table de routage. 04:32.770 --> 04:36.790 Il peut s'agir d'une simple liste des entrées de la table de routage. 04:36.820 --> 04:38.770 Qu'est-ce qu'une entrée dans la table de routage ? 04:38.800 --> 04:43.090 Chaque ligne de cette table de routage est appelée entrée de la table de routage. 04:43.420 --> 04:49.960 Ainsi, si vous maintenez une liste de liens de ces entrées de la table de routage, cette liste de liens représente en fait 04:49.960 --> 04:51.280 votre table de routage. 04:53.600 --> 05:00.440 L'administrateur peut maintenant effectuer des opérations d'insertion, de mise à jour et de suppression sur cette table de routage. 05:01.270 --> 05:01.930 C'est vrai. 05:01.930 --> 05:09.340 Ainsi, pour insérer une nouvelle entrée dans cette table de routage, l'administrateur doit spécifier les trois valeurs qui correspondent 05:09.340 --> 05:16.210 aux trois champs de la table de routage, à savoir le masque de destination, la passerelle, l'adresse IP et l'interface sortante. 05:16.810 --> 05:17.380 C'est vrai. 05:17.380 --> 05:24.040 De même, pour mettre à jour une entrée existante dans la table de routage, l'administrateur doit spécifier le masque de destination, 05:24.040 --> 05:28.810 la nouvelle adresse IP de la passerelle et la nouvelle interface de sortie. 05:29.110 --> 05:35.710 Vous devez rechercher cette entrée dans la table de routage en utilisant le masque de destination comme clé. 05:36.660 --> 05:43.200 Une fois que vous avez localisé cette entrée dans la table de routage, remplacez simplement l'ancienne adresse IP de la passerelle et l'ancienne 05:43.200 --> 05:46.020 interface de sortie par ces nouvelles valeurs. 05:46.410 --> 05:49.530 Cette opération est donc appelée opération de mise à jour. 05:50.100 --> 05:55.770 La troisième opération que l'administrateur peut effectuer sur cette table de routage est en fait une opération 05:55.770 --> 05:57.090 de suppression. 05:57.090 --> 06:04.710 Tout ce que vous devez spécifier est la destination et la valeur du masque, car il s'agit d'une clé permettant d'identifier une entrée particulière 06:04.710 --> 06:06.480 dans la table de routage. 06:07.380 --> 06:13.620 Une fois que vous êtes en mesure de trouver cette entrée particulière dans la table de routage en utilisant la destination et le masque 06:13.620 --> 06:17.280 comme clé, supprimez simplement cette entrée de la table de routage. 06:17.460 --> 06:23.850 Voici donc les trois opérations qu'un administrateur peut effectuer sur une table de routage 06:23.850 --> 06:26.460 gérée par un processus RTM. 06:26.640 --> 06:34.110 Une fois que le processus RTM modifie l'état d'une table de routage en vertu de ces trois opérations effectuées par l'administrateur, 06:34.110 --> 06:41.730 le processus de gestion de la table de routage doit synchroniser l'état ou la modification de la table de routage avec 06:41.730 --> 06:45.390 tous les autres clients connectés. 06:46.830 --> 06:54.840 Voyons donc comment cela peut se faire chaque fois que l'utilisateur effectue une opération sur la table de routage. 06:54.870 --> 07:01.950 Le processus de gestion de la table de routage doit synchroniser cette opération particulière avec tous les clients connectés. 07:02.250 --> 07:04.860 Lorsqu'un nouveau client se connecte au serveur. 07:04.980 --> 07:10.530 Supposons maintenant qu'il y ait n nombre de clients déjà connectés à notre processus. 07:10.530 --> 07:14.700 Et supposons qu'un nouveau client arrive et se connecte au serveur. 07:14.850 --> 07:20.310 Ce nouveau client ne sait rien de l'état de la table de routage, n'est-ce pas ? 07:20.310 --> 07:25.500 Ainsi, à ce stade, lorsque le serveur reçoit la demande d'établissement de connexion 07:25.500 --> 07:32.490 du nouveau client et que la connexion est entièrement établie, il incombe au processus RTM d'envoyer l'instantané 07:32.490 --> 07:37.710 complet de la table de routage à ce client nouvellement connecté. 07:38.500 --> 07:39.190 C'est vrai. 07:39.430 --> 07:44.170 C'est ce qu'on appelle le vidage de la table de routage, c'est-à-dire l'opération de vidage. 07:44.740 --> 07:54.110 Ainsi, à tout moment, la table de routage doit être identique sur le processus RTM ainsi que sur tous les clients connectés. 07:54.130 --> 07:56.650 C'est ce que vous pouvez voir dans ce diagramme. 07:58.080 --> 08:03.960 Le processus est ici et ce processus est en charge de la table de routage. 08:04.230 --> 08:09.870 Nous avons d'autres processus clients qui s'exécutent sur la même machine et ces processus clients 08:09.870 --> 08:12.210 sont connectés à notre processus RTM. 08:12.240 --> 08:18.300 Supposons maintenant qu'à un moment donné, ce processus client particulier ait 08:18.300 --> 08:22.680 le même état de la table de routage que ce processus RTM. 08:22.890 --> 08:29.100 Les autres clients ont également le même état de la table de routage, mais je n'ai pas d'espace pour dessiner 08:29.100 --> 08:32.220 la même table de routage pour les deux autres clients. 08:32.250 --> 08:38.790 Par conséquent, je n'ai dessiné cette table de routage que pour ce client, mais je suppose que tous les clients connectés 08:38.790 --> 08:41.610 ont le même état de la table de routage. 08:43.760 --> 08:52.070 Maintenant, dans cet exemple, supposons qu'il s'agisse d'un client, A la table de routage du client A est en parfaite synchronisation 08:52.070 --> 08:54.860 avec la table de routage des processus RTM. 08:55.160 --> 09:02.120 Supposons maintenant qu'un administrateur effectue une opération sur RTM et ajoute une nouvelle entrée dans cette table de routage. 09:03.010 --> 09:10.090 La responsabilité du processus Altium est de synchroniser cet ajout particulier d'une nouvelle entrée 09:10.090 --> 09:13.240 avec tous les processus clients connectés. 09:14.310 --> 09:21.780 Notre processus doit donc transmettre à tous les clients connectés l'information selon laquelle une nouvelle donnée a été 09:21.780 --> 09:23.580 ajoutée à la table de routage. 09:23.940 --> 09:29.880 Le processus RTM transmet donc cette information en utilisant le format suivant. 09:30.730 --> 09:32.290 Qu'est-ce que ce format ? 09:32.320 --> 09:34.870 Ce format contient deux champs. 09:34.870 --> 09:39.430 Le premier champ indique si l'entrée est créée, mise à jour ou supprimée. 09:39.460 --> 09:45.310 Par conséquent, le premier champ est également appelé code d'opération, et le deuxième champ est en 09:45.310 --> 09:48.460 fait la donnée qui a été ajoutée à la table de routage. 09:48.610 --> 09:56.050 Dans cet exemple, le processus RTM doit donc communiquer aux autres clients qu'une nouvelle entrée vient d'être ajoutée 09:56.050 --> 09:57.370 à la table de routage. 09:58.480 --> 10:05.020 Lorsque le processus client reçoit l'information du processus RTM concernant 10:05.020 --> 10:11.140 la mise à jour de la table de routage, il traite cette mise à jour et la notification 10:11.140 --> 10:14.920 reçue du processus RTM. 10:15.250 --> 10:21.790 En conséquence, la table de routage du processus client est synchronisée avec la table de routage 10:21.790 --> 10:23.200 du processus RTM. 10:24.960 --> 10:32.160 De même, lorsque l'administrateur supprime ou met à jour l'entrée de la table de routage du processus RTM, ce dernier 10:32.160 --> 10:35.760 doit envoyer le code d'opération correspondant. 10:35.760 --> 10:42.300 En d'autres termes, il peut être mis à jour ou supprimé en même temps que les données pour tous les autres clients connectés. 10:42.540 --> 10:49.710 L'objectif final est donc qu'à tout moment, l'état de la table de routage de tous les clients 10:49.710 --> 10:55.590 soit exactement le même que l'état de la table de routage du processus RTM. 10:56.280 --> 11:01.980 Examinons maintenant rapidement les structures de données que vous souhaitez utiliser pour mettre en œuvre ce mécanisme 11:01.980 --> 11:03.870 de synchronisation des données. 11:04.680 --> 11:12.360 Nous avons donc discuté de la nécessité de disposer de trois codes d'opération, à savoir la création, la mise à jour et la suppression. 11:13.230 --> 11:18.870 Le code d'opération Create correspond à la création d'une nouvelle entrée dans la table de routage du processus RTM. 11:18.900 --> 11:26.800 La mise à jour correspond à l'actualisation de l'entrée existante dans la table de routage sur le processus RTM. 11:26.800 --> 11:33.400 De même, le code d'opération de suppression sera utilisé lorsque l'administrateur essaiera de supprimer des données. 11:34.110 --> 11:41.490 L'entrée de la table de routage vous permet d'utiliser ces codes d'opération et de les définir en tant qu'énumération. 11:42.190 --> 11:43.000 Aujourd'hui. 11:43.000 --> 11:48.010 Deuxièmement, vous avez besoin d'une structure qui représente une entrée de la table de routage. 11:48.720 --> 11:55.950 Vous pouvez donc voir que l'entrée de la table de routage se compose de quatre informations : le masque de destination, 11:55.950 --> 11:58.590 la passerelle et l'interface de sortie. 11:58.920 --> 12:05.520 Dans la table de routage, la destination et le masque forment ensemble une clé. 12:06.120 --> 12:13.290 Pour identifier de manière unique une entrée de la table de routage, vous devez donc utiliser la destination et la valeur 12:13.290 --> 12:14.970 du masque comme clé. 12:15.180 --> 12:21.780 Maintenant, lorsque le processus RTM doit envoyer la notification au reste des autres clients, il doit 12:21.780 --> 12:25.180 envoyer la notification en utilisant ce message. 12:25.200 --> 12:33.510 Ce message est donc en fait un mélange du code d'opération qui peut être la création, la mise à jour ou la suppression. 12:34.550 --> 12:42.230 Le deuxième champ, le corps du message, peut être utilisé pour envoyer les données exactes qui sont ajoutées ou mises 12:42.230 --> 12:45.620 à jour dans la table de routage du processus RTM. 12:46.590 --> 12:47.100 C'est vrai. 12:47.100 --> 12:53.010 Je discute donc de cette structure de données afin de vous aider à concevoir votre projet. 12:53.250 --> 12:59.880 J'espère donc que la fonctionnalité du projet est claire. Lorsque nous aborderons d'autres 12:59.880 --> 13:08.310 mécanismes IPC dans ce cours, nous étendrons ce projet et y ajouterons davantage de complexité et de fonctionnalité. 13:08.760 --> 13:11.880 Veuillez donc passer au module deux. 13:11.910 --> 13:17.100 Il s'agit du mécanisme IPC suivant, qui ne sera mis en place que lorsque vous aurez achevé ce projet. 13:17.400 --> 13:22.080 Voilà pour la communication inter-processus basée sur les sockets du domaine Unix.