WEBVTT 00:05.520 --> 00:11.340 Maintenant, discutons du projet sur la mémoire partagée en tant que communication inter-processus. 00:11.550 --> 00:18.330 Dans ce projet, nous allons donc étendre le projet que vous avez réalisé sur les sockets de domaine Unix dans 00:18.330 --> 00:25.410 le module précédent. Dans le projet de socket de domaine Unix, le processus serveur du gestionnaire de table de 00:25.440 --> 00:34.650 routage (RTM) a synchronisé sa table de routage locale avec tous les clients connectés en utilisant le socket de domaine Unix comme IPC. 00:35.340 --> 00:40.290 Dans ce projet, le processus RTM gère également une autre table. 00:40.290 --> 00:50.360 Disons que cette table est appelée table ARP et qu'elle synchronise cette table avec tous les clients abonnés. 00:50.370 --> 00:56.820 Les clients abonnés sont des clients connectés à l'aide d'une approche IPC à mémoire partagée. 00:58.200 --> 01:01.200 Examinons donc le projet étape par étape. 01:01.200 --> 01:04.860 La fonctionnalité du projet précédent restera inchangée. 01:05.190 --> 01:09.870 La fonctionnalité du projet précédent n'est absolument pas modifiée. 01:11.400 --> 01:17.640 Dans ce projet, nous ne faisons donc qu'étendre la fonctionnalité du projet. 01:19.260 --> 01:26.280 Discutons donc de ce projet étape par étape pour voir ce que nous cherchons à mettre en œuvre. 01:27.390 --> 01:34.200 Vous pouvez donc voir qu'il y a un processus serveur Rtmp et deux processus clients qui tournent 01:34.200 --> 01:35.940 sur la même machine. 01:35.970 --> 01:40.950 Appelons ce processus client : client A, client B et client C. 01:41.790 --> 01:42.510 C'est vrai. 01:42.510 --> 01:50.820 Ainsi, dans ce projet, le processus RTM est également en charge d'un ensemble d'adresses Mac. 01:51.360 --> 01:59.190 Vous pouvez donc voir dans ce diagramme que notre processus RTM maintient un ensemble d'adresses Mac dans sa mémoire locale parce 01:59.370 --> 02:04.380 que ces adresses Mac sont maintenues dans la mémoire locale du processus. 02:04.410 --> 02:07.620 Il s'agit donc d'une mémoire de processus. 02:08.360 --> 02:14.060 Notez donc que cette liste d'adresses Mac est maintenue dans le processus RTM. 02:14.060 --> 02:19.280 Mémoire locale correspondant à chaque adresse Mac de cette liste. 02:19.310 --> 02:23.150 Il existe une adresse IP dans la mémoire partagée. 02:23.800 --> 02:24.370 C'est vrai. 02:24.370 --> 02:28.780 N'oubliez donc pas que la mémoire partagée est toujours accessible à l'aide d'une clé. 02:29.170 --> 02:34.930 Cette adresse Mac, qui est la première adresse Mac, est donc une clé pour la première adresse IP. 02:35.530 --> 02:42.630 De même, la deuxième adresse Mac de cette liste est une clé pour la deuxième adresse IP dans la mémoire partagée, 02:42.640 --> 02:43.930 et ainsi de suite. 02:45.450 --> 02:52.590 Cela signifie que le processus RTM peut accéder à l'adresse IP stockée dans la mémoire partagée en utilisant l'adresse 02:52.590 --> 02:54.180 Mac comme clé. 02:55.710 --> 02:58.080 Maintenant, à tout moment. 02:59.010 --> 03:06.840 La liste de ces adresses Mac doit être synchronisée avec la liste des adresses Mac de tous les autres processus 03:06.840 --> 03:07.770 clients. 03:08.450 --> 03:12.290 Par souci de clarté, je vous montre donc. 03:12.910 --> 03:20.860 La liste des adresses Mac ne concerne que le processus client et vous pouvez voir que la liste des adresses Mac. 03:21.530 --> 03:27.890 du processus client B est exactement la même que la liste des adresses Mac du processus RTM. 03:28.040 --> 03:35.660 A nouveau, la synchronisation des adresses Mac entre le processus RTM et les processus clients doit être effectuée 03:35.660 --> 03:39.620 en utilisant les sockets de domaine Unix comme IPC. 03:41.580 --> 03:49.470 Supposons maintenant que l'administrateur ajoute une nouvelle adresse Mac à la liste des adresses Mac du processus 03:49.500 --> 03:50.400 RTM. 03:51.050 --> 03:54.560 Ici, l'administrateur ajoute une nouvelle entrée. 03:55.340 --> 04:00.230 Maintenant, parce que l'administrateur a ajouté une nouvelle entrée dans la clé d'adresse Mac. 04:00.260 --> 04:05.060 N'oubliez pas que ces adresses Mac sont les clés du contenu de la mémoire partagée. 04:05.090 --> 04:11.930 Par conséquent, l'administrateur doit également insérer un contenu dans la mémoire partagée pour cette nouvelle clé. 04:12.290 --> 04:15.110 Vous pouvez donc voir le contenu de la mémoire partagée. 04:15.140 --> 04:16.970 Il dispose désormais d'une adresse IP. 04:16.970 --> 04:19.700 122. 1. 2. 3. 04:21.300 --> 04:27.240 La clé nouvellement ajoutée à l'adresse Mac est donc cette clé. 04:28.210 --> 04:31.780 Correspond à cette valeur dans la mémoire partagée. 04:32.840 --> 04:40.850 Ainsi, lorsque l'administrateur saisit la paire d'adresses Mac et IP dans le processus RTM, ce dernier doit enregistrer 04:40.910 --> 04:48.650 l'adresse Mac dans sa liste d'adresses Mac et l'adresse IP doit être ajoutée à la région de mémoire partagée nouvellement 04:48.650 --> 04:50.030 créée. 04:50.060 --> 04:57.530 Une fois que l'administrateur a saisi avec succès la nouvelle adresse Mac et la nouvelle adresse IP dans 04:57.530 --> 05:05.360 le processus RTM, il incombe à ce dernier de synchroniser tout changement dans la liste d'adresses Mac du processus 05:05.360 --> 05:09.410 RTM avec tous les autres clients connectés. 05:09.530 --> 05:18.080 Vous pouvez donc voir dans ce diagramme que le processus RTM envoie une mise à jour à tous les autres clients connectés et que cette 05:18.080 --> 05:22.490 mise à jour est envoyée à l'aide d'une socket de domaine Unix. 05:22.820 --> 05:31.100 Notez maintenant que le processus RTM envoie le code d'opération C, qui signifie Créer. 05:31.130 --> 05:38.430 Créer signifie que la nouvelle adresse Mac a été ajoutée à la liste des adresses Mac du processus RTM. 05:38.670 --> 05:46.650 Le deuxième champ de cette notification est l'adresse Mac actuelle qui a été ajoutée à la liste d'adresses 05:46.650 --> 05:49.170 Mac du processus RTM. 05:49.530 --> 05:56.820 Maintenant, lorsque le client reçoit cette mise à jour sur la notification du processus RTM, il effectue la même 05:56.820 --> 05:59.560 opération sur sa liste d'adresses Mac. 05:59.580 --> 06:04.710 Le client ajoute donc également la nouvelle adresse Mac à sa liste d'adresses Mac. 06:05.100 --> 06:11.010 N'oubliez pas que cette notification est envoyée à tous les autres clients qui fonctionnent sur le système, c'est-à-dire 06:11.010 --> 06:12.750 le client A et le client. 06:12.780 --> 06:13.680 Voir aussi 06:13.710 --> 06:21.480 Toutefois, par souci de clarté, j'essaie d'expliquer le projet uniquement en montrant le processus B du client 06:21.510 --> 06:23.130 à titre d'exemple. 06:24.100 --> 06:31.690 Vous pouvez donc voir qu'une fois que le processus client B a reçu une adresse Mac nouvellement créée en utilisant cette nouvelle adresse 06:31.720 --> 06:37.870 Mac, qui vient d'être ajoutée à la liste des adresses Mac du processus client, le processus client peut maintenant 06:37.870 --> 06:40.870 accéder au contenu de la mémoire partagée. 06:41.140 --> 06:47.260 Ainsi, dans ce projet, le processus client se contente de lire le contenu de la mémoire partagée et de l'imprimer 06:47.260 --> 06:48.100 à l'écran. 06:49.680 --> 06:57.690 Ainsi, lorsque l'administrateur ajoute une paire d'adresses Mac et IP au processus RTM, ce dernier met 06:57.690 --> 07:04.170 à jour sa liste d'adresses Mac avec l'adresse Mac et met à jour la mémoire partagée avec 07:04.170 --> 07:05.490 l'adresse IP. 07:06.030 --> 07:12.630 L'adresse mac est en fait une clé de l'adresse IP qui est stockée dans la mémoire partagée. 07:13.400 --> 07:21.170 Ensuite, le processus Altium se contente de synchroniser ou de notifier ce changement au reste du processus client 07:21.170 --> 07:23.660 qui s'exécute sur le même système. 07:25.930 --> 07:32.620 Une fois que le processus client a reçu cette clé du processus RTM, il effectue la même opération 07:32.620 --> 07:35.110 sur sa liste d'adresses Mac. 07:35.140 --> 07:36.130 C'est-à-dire qu'il. 07:36.130 --> 07:41.620 Créez ou supprimez la clé d'adresse Mac de sa liste de tables d'adresses Mac. 07:42.710 --> 07:47.840 Essayons donc d'illustrer à nouveau l'ensemble de ce projet. 07:48.550 --> 07:55.090 Ainsi, dans ce projet, tous les processus, qu'il s'agisse d'un processus RTM ou d'un processus client, sont censés ne stocker 07:55.090 --> 08:00.830 que la clé de mémoire partagée, c'est-à-dire l'adresse Mac, dans leur structure de données interne. 08:00.850 --> 08:07.210 Rappelez-vous donc que la clé de la mémoire partagée est constituée par les adresses Mac, et que chaque processus 08:07.210 --> 08:12.370 de ce projet conserve la liste des adresses Mac dans ses structures de données internes. 08:13.390 --> 08:19.870 Vous pouvez donc voir dans ce diagramme que nous avons une mémoire partagée et que le processus RTM maintient la 08:19.870 --> 08:26.260 liste des adresses Mac ainsi que le processus client, qui maintient également la même liste d'adresses Mac. 08:27.040 --> 08:33.220 Le processus du serveur ajoute maintenant les données correspondant à une nouvelle adresse Mac. 08:33.250 --> 08:40.480 Il ajoute une adresse IP à la mémoire partagée et il y a donc toujours une correspondance 1 à 1 entre les adresses 08:40.480 --> 08:45.670 Mac et les adresses IP qui sont stockées dans la mémoire partagée. 08:45.700 --> 08:49.060 Vous pouvez donc voir que le Mac est la clé de l'adresse IP. 08:49.060 --> 08:53.710 IP one, Mac two est la clé de l'adresse IP, IP two et ainsi de suite. 08:54.430 --> 09:01.810 Ainsi, dans le processus RTM, chaque fois qu'il y a un changement dans la liste des adresses Mac maintenue par 09:01.810 --> 09:10.240 le processus RTM, le processus RTM synchronise ou notifie uniquement les adresses Mac au reste des clients connectés en utilisant 09:10.240 --> 09:12.850 des sockets de domaine Unix. 09:13.540 --> 09:14.100 C'est vrai. 09:14.170 --> 09:21.550 Ainsi, par exemple, supposons que le processus RTM ajoute une nouvelle adresse Mac for dans sa liste d'adresses Mac et qu'il ajoute 09:21.550 --> 09:26.350 l'adresse IP correspondant à cette adresse Mac dans la mémoire partagée. 09:26.500 --> 09:35.430 Ainsi, le processus RTM utilisant des sockets de domaine Unix ne fait que synchroniser ou transmettre l'ajout de nouvelles adresses 09:35.440 --> 09:37.870 Mac for au processus client. 09:39.180 --> 09:48.420 Ainsi, lorsque le processus client, ayant reçu cette nouvelle clé qui est Mac pour le processus client, stocke cette nouvelle adresse Mac dans 09:48.420 --> 09:56.100 sa propre liste privée et en utilisant cette adresse Mac comme clé de mémoire partagée, les processus clients peuvent 09:56.100 --> 10:02.910 également accéder à l'adresse IP correspondante qui a été ajoutée par le processus serveur dans la mémoire 10:02.940 --> 10:04.310 partagée. 10:04.350 --> 10:13.470 Vous pouvez donc voir qu'une fois que le processus client a reçu Mac for du processus RTM, le processus client peut maintenant 10:13.470 --> 10:19.860 accéder à la mémoire partagée et lire l'adresse IP for dans la mémoire partagée. 10:20.860 --> 10:27.790 Et lorsque le nouveau client se connecte au processus du serveur, parce qu'un client peut arriver à 10:27.790 --> 10:31.570 tout moment et se connecter au processus du serveur. 10:31.600 --> 10:37.810 Ainsi, comme dans le projet précédent, le serveur était censé synchroniser ou transférer l'intégralité de la table de routage 10:37.840 --> 10:39.980 à ce client nouvellement connecté. 10:40.000 --> 10:44.800 Dans ce projet, nous ferons la même chose en plus de la table de routage. 10:44.800 --> 10:53.590 Le processus synchronise également l'ensemble de la liste d'adresses Mac locale avec ce nouveau client à l'aide d'une socket de domaine 10:53.590 --> 10:54.520 Unix. 10:55.060 --> 11:02.770 Ainsi, le client nouvellement connecté obtiendra toutes les informations relatives à la table de routage 11:02.770 --> 11:03.970 et à la table mac. 11:05.360 --> 11:12.470 Via le socket de domaine Unix et la mémoire partagée ipxe du processus RTM. 11:13.650 --> 11:17.550 J'espère donc que le projet sera intéressant et simple. 11:17.580 --> 11:19.290 Bonne chance à tous.