WEBVTT 00:05.590 --> 00:08.620 Alors les gars, discutons du projet sur les signaux. 00:09.400 --> 00:15.490 Dans ce projet, nous continuerons donc à étendre le même projet que nous avons réalisé dans ce cours. 00:16.480 --> 00:23.920 Jusqu'à présent, lorsqu'un nouveau client se connecte au processus serveur, c'est-à-dire au processus serveur RTM, il synchronise 00:23.920 --> 00:32.200 l'ensemble de sa table de routage et de sa table ARP avec le nouveau client connecté en utilisant respectivement la socket de domaine Unix et 00:32.200 --> 00:34.300 la mémoire partagée. 00:34.780 --> 00:40.930 Nous avons donc déjà mis en œuvre cette méthode dans le cadre des deux projets précédents de ce cours. 00:41.530 --> 00:45.160 Nous allons maintenant ajouter une nouvelle fonctionnalité à ce projet. 00:46.320 --> 00:53.880 Maintenant, lorsqu'un nouveau client se connecte au processus du serveur et... 00:54.880 --> 00:59.230 Une fois que le processus du serveur Altium a terminé la synchronisation des données. 01:00.180 --> 01:03.750 La table de routage et la table ARP de ce nouveau client. 01:03.780 --> 01:10.590 Par la suite, ce nouveau client envoie son propre identifiant de processus, n'est-ce pas ? 01:10.590 --> 01:17.250 Ainsi, dans un programme C, vous pouvez obtenir l'ID du processus d'un programme C à l'aide de la fonction get PID. 01:18.040 --> 01:18.610 C'est vrai. 01:18.610 --> 01:27.160 Ce nouveau client enverra donc son propre identifiant de processus au processus du serveur RTM et il enverra cet identifiant de processus 01:27.160 --> 01:32.650 au processus du serveur RTM en utilisant la socket de domaine Unix comme IPC. 01:33.930 --> 01:41.820 Vous pouvez donc voir que le client A, le client B et le client C viennent de se connecter à notre processus serveur 01:41.820 --> 01:49.140 et que la synchronisation entre notre processus serveur et tous ces clients vient de se terminer. 01:49.350 --> 01:55.200 Maintenant, lorsque la synchronisation vient de se terminer, les clients sont censés envoyer leur identifiant de processus 01:55.440 --> 01:59.070 au processus serveur en utilisant des sockets de domaine Unix. 02:00.790 --> 02:07.390 Lorsque le serveur reçoit l'ID de processus de tous les clients nouvellement connectés, il stocke 02:07.390 --> 02:10.060 leur ID de processus dans un tableau. 02:10.480 --> 02:16.930 Ainsi, sur un processus serveur, vous pouvez supposer qu'il y a un tableau qui va stocker l'ID de processus de tous 02:16.930 --> 02:19.420 les clients nouvellement connectés. 02:20.770 --> 02:26.340 Désormais, vous pouvez ajouter un choix dans un menu côté serveur. 02:26.350 --> 02:31.180 En d'autres termes, vous pouvez ajouter une option supplémentaire côté serveur. 02:32.370 --> 02:39.990 Et lorsque l'administrateur choisit cette option particulière, le serveur doit vider l'ensemble de sa table de routage 02:40.020 --> 02:43.290 et de sa table ARP dans la mémoire partagée. 02:45.270 --> 02:45.720 C'est vrai. 02:45.720 --> 02:53.310 Cela signifie que le processus serveur va supprimer l'ensemble du contenu de sa table de routage et de sa table 02:53.310 --> 02:58.170 ARP de sa mémoire de processus ainsi que de sa mémoire partagée. 02:59.610 --> 03:08.100 Maintenant, après la vidange, le processus serveur RTM envoie un signal à User1. Ce signal est envoyé à tous les 03:08.100 --> 03:12.160 clients connectés en utilisant leurs pids avec Gil. 03:12.180 --> 03:18.960 Nous avons déjà appris à utiliser la commande Gil, donc en utilisant cette commande kill, le processus serveur 03:18.960 --> 03:22.830 est censé envoyer ce signal à tous les clients connectés. 03:23.010 --> 03:30.300 Lorsque tous les clients connectés reçoivent ce signal, ils sont censés effacer leur propre table 03:30.300 --> 03:33.900 de routage ainsi que les copies de notre table. 03:34.260 --> 03:42.330 L'intention est donc que le processus RTM envoie un signal au reste des clients connectés et que les clients connectés 03:42.720 --> 03:49.860 ayant reçu ce signal soient censés vider leurs structures de données internes, à savoir la table de 03:49.860 --> 03:52.350 routage et la table ARP. 03:53.370 --> 03:53.970 C'est vrai. 03:53.970 --> 04:00.000 La dernière fonctionnalité que vous pouvez ajouter à ce projet est que lorsque le client 04:00.000 --> 04:08.490 met fin à la connexion au domaine Unix avec le processus RTM, il doit nettoyer toutes les tables qu'il maintient. 04:08.490 --> 04:15.630 En d'autres termes, le client doit nettoyer, détruire ou libérer la table de routage ainsi que la table ARP. 04:15.720 --> 04:16.530 C'est vrai. 04:16.740 --> 04:21.660 Avant de fermer la connexion, le client doit envoyer un dernier message au serveur. 04:22.050 --> 04:22.650 C'est vrai. 04:22.650 --> 04:23.940 Il s'agit donc d'un message spécial. 04:23.940 --> 04:25.920 Il pourrait s'agir d'un message d'adieu. 04:26.040 --> 04:33.270 Lorsque le serveur reçoit ce message d'adieu du client, il est censé supprimer l'identifiant 04:33.270 --> 04:36.750 du processus de ce client de la liste. 04:37.020 --> 04:39.210 Il s'agit de cette liste. 04:39.210 --> 04:45.480 Le processus du serveur RTM va supprimer l'ID du processus du client qui vient d'envoyer le message d'adieu 04:45.480 --> 04:47.760 au processus du serveur RTM. 04:48.780 --> 04:53.190 Il s'agit donc de la dernière fonctionnalité que vous pouvez ajouter à ce projet. 04:54.060 --> 04:56.190 C'est ce que l'on peut constater à travers ce projet. 04:56.190 --> 05:02.310 Nous avons en fait pratiqué la plupart des techniques IPC que nous avons apprises dans ce cours. 05:02.520 --> 05:08.160 Dans le cadre de ce projet, nous avons appris à déployer la communication en utilisant des sockets de domaine Unix. 05:08.190 --> 05:15.330 Nous avons appris à déployer la communication en utilisant la mémoire partagée, et nous avons également utilisé des signaux 05:15.330 --> 05:20.880 afin d'évacuer l'ensemble de la table de routage et de la table ARP des processus clients. 05:21.570 --> 05:23.530 J'espère que ce projet vous a plu. 05:23.550 --> 05:24.600 Bonne chance.