WEBVTT 00:04.880 --> 00:12.140 Il est temps de discuter de la mise en œuvre d'un exemple simple de communication basée sur une file de messages. 00:12.350 --> 00:18.680 Vous pouvez donc télécharger le code source à partir de cette URL GitHub et vous devez aller dans ce répertoire. 00:18.680 --> 00:23.320 A l'intérieur de ce répertoire, vous trouverez deux fichiers C, à savoir les émetteurs et les récepteurs. 00:23.780 --> 00:29.060 Je vais donc vous montrer comment les processus d'envoi et de réception peuvent communiquer entre eux en utilisant 00:29.060 --> 00:31.130 la file d'attente de messages comme IPC. 00:32.270 --> 00:37.640 Vous pouvez donc télécharger le code comme suit en utilisant la commande git clone. 00:43.170 --> 00:47.550 Cette commande va vous permettre de télécharger le répertoire IPC sur votre machine locale. 00:47.640 --> 00:50.880 Assurez-vous que votre machine Linux est connectée à l'internet. 00:52.170 --> 00:57.950 Dans ce répertoire IPC, vous trouverez un répertoire de file d'attente de messages, dans 00:57.990 --> 01:04.380 lequel vous trouverez les fichiers sender et receiver dot c qui implémentent le processus d'envoi 01:04.380 --> 01:05.540 et de réception. 01:05.550 --> 01:09.570 J'ai donc divisé la fenêtre en deux fenêtres sur le côté gauche. 01:09.570 --> 01:15.840 Essayons de comprendre le code du processus d'envoi qui est le sandboxie. 01:16.960 --> 01:19.960 Vous pouvez donc constater que la mise en œuvre est relativement limitée. 01:20.860 --> 01:24.130 Vous pouvez donc voir sur le côté gauche que j'ai un processus de ponçage. 01:24.130 --> 01:29.560 Le processus de ponçage a donc besoin d'une mémoire appelée tampon dans laquelle il stocke d'abord les 01:29.590 --> 01:32.170 données à envoyer au processus de réception. 01:32.410 --> 01:33.160 C'est vrai ? 01:33.160 --> 01:40.360 Le processus d'envoi demande donc à l'utilisateur de saisir la chaîne, qui sera utilisée par le processus de 01:40.360 --> 01:44.410 ponçage pour envoyer des données au processus de réception. 01:44.530 --> 01:48.700 Ici, le processus de ponçage consiste simplement à demander à l'utilisateur d'entrer une chaîne de caractères. 01:49.540 --> 01:56.320 Le droit et l'endroit où ce processus de ponçage obtiendra l'ID de la file d'attente de messages du processus de réception. 01:57.510 --> 02:03.600 Ainsi, lorsque nous lancerons ce processus, nous transmettrons l'ID du message du processus de réception en 02:03.600 --> 02:06.660 tant qu'argument de la ligne de commande d'exécution. 02:06.840 --> 02:07.500 C'est vrai. 02:07.500 --> 02:12.530 Comme nous le savons, en C, l'argument de la ligne de commande d'exécution est stocké dans ce tableau. 02:12.540 --> 02:17.910 Vous pouvez donc constater que si le nombre d'arguments transmis est inférieur à un, cela signifie que l'utilisateur 02:17.910 --> 02:24.270 n'a pas transmis l'ID de message du processus de réception et que ce processus affiche donc une erreur indiquant qu'il s'attend 02:24.270 --> 02:28.800 à ce que l'ID de message soit transmis en tant qu'argument d'exécution. 02:30.910 --> 02:36.790 Notez donc toujours que le processus d'envoi doit connaître l'ID du message du processus de réception afin que le processus d'envoi 02:36.790 --> 02:41.410 puisse envoyer des données au processus de réception à l'aide d'une file d'attente de messages. 02:41.500 --> 02:47.950 Ainsi, à la ligne 30, nous supposons que nous avons fourni l'argument de ligne de commande à ce processus. 02:48.130 --> 02:51.340 Ce processus ouvrira donc simplement la file d'attente des messages. 02:51.340 --> 02:56.980 Le nom de la file d'attente de messages est bien sûr stocké dans ce tableau d'arguments de la ligne de commande. 02:56.980 --> 03:03.340 Ce processus ouvre en fait la file d'attente des messages en mode écriture uniquement, car tout ce qu'il a besoin de faire 03:03.340 --> 03:10.060 est d'envoyer un message au processus destinataire en utilisant la file d'attente des messages et l'argument restant peut être 03:10.060 --> 03:11.650 passé comme null null. 03:11.680 --> 03:16.540 À ce stade, le processus a donc réussi à ouvrir une file d'attente de messages. 03:17.290 --> 03:23.920 Le processus a également reçu avec succès l'entrée de l'utilisateur à l'aide de l'instruction Scanf. 03:24.530 --> 03:31.370 La dernière chose que fait ce processus est donc d'envoyer les données au processus de réception à l'aide de l'API d'envoi de la file d'attente 03:31.370 --> 03:32.600 de messages. 03:35.110 --> 03:40.540 Une fois que le processus a envoyé avec succès les données au processus destinataire, il ferme simplement la file 03:40.540 --> 03:42.550 d'attente des messages et se termine. 03:42.580 --> 03:47.140 Vous pouvez donc constater que la mise en œuvre du processus d'envoi est relativement simple. 03:47.780 --> 03:50.310 De même, dans la fenêtre de droite. 03:50.330 --> 03:53.600 Examinons la mise en œuvre de la procédure de réception. 03:57.290 --> 04:00.890 La mise en œuvre du processus de réception est donc également assez simple. 04:01.460 --> 04:07.010 Ainsi, lorsque nous lançons ce processus de réception, nous fournissons à nouveau l'argument de ligne de commande comme nom de 04:07.010 --> 04:10.110 l'identifiant de message en utilisant cet identifiant de message. 04:10.130 --> 04:13.790 Ce processus de réception va créer sa propre file d'attente de messages. 04:15.440 --> 04:16.130 C'est vrai. 04:16.130 --> 04:19.320 Nous définissons ici les attributs de la file d'attente de messages. 04:19.340 --> 04:22.430 Nous ne définissons donc que deux attributs de la file d'attente de messages. 04:22.460 --> 04:28.790 Il s'agit de la taille maximale du message qui peut être placé dans la file d'attente et du nombre maximal de messages 04:28.790 --> 04:32.630 qui peuvent être mis en file d'attente dans une file d'attente. 04:33.270 --> 04:39.750 Maintenant, après avoir spécifié les attributs de la file d'attente de messages à la ligne 36, le processus de réception peut simplement 04:39.750 --> 04:44.460 créer une file d'attente de messages à l'aide de l'API d'ouverture de file d'attente de messages. 04:44.490 --> 04:49.860 Le premier argument de cette API est donc l'argument de la ligne de commande, qui est en fait une chaîne ou un identifiant 04:49.860 --> 04:52.500 de file d'attente de messages fourni par l'utilisateur. 04:52.500 --> 04:58.590 Et comme il s'agit d'un processus de réception, il suffit que ce processus ouvre une file d'attente de messages en 04:58.590 --> 04:59.790 mode lecture seule. 05:00.120 --> 05:00.750 C'est vrai ? 05:00.750 --> 05:05.010 Ce processus peut définir certaines autorisations pour sa file d'attente de messages. 05:05.010 --> 05:11.730 Le dernier argument fourni à l'API d'ouverture de la file d'attente de messages est le pointeur vers les attributs que nous venons de 05:11.730 --> 05:15.810 définir avant d'invoquer l'API d'ouverture de la file d'attente de messages. 05:16.320 --> 05:21.810 C'est-à-dire que ces attributs et les permissions peuvent toujours être utilisés comme 0660. 05:22.640 --> 05:28.880 Ici, nous avons également pris la variable set, dans laquelle nous allons stocker le descripteur de fichier de la file d'attente 05:28.880 --> 05:29.690 des messages. 05:31.450 --> 05:36.350 Notre processus de réception entre donc dans une boucle infinie. 05:36.370 --> 05:43.120 La première chose que fait ce processus de réception est donc d'effacer tous les descripteurs de fichiers présents 05:43.120 --> 05:45.550 dans cette structure de données. 05:45.670 --> 05:52.780 Ensuite, il suffit d'ajouter le descripteur de fichier de la file d'attente de messages que le processus de réception vient de 05:52.780 --> 05:55.030 créer dans cette structure de données. 05:55.810 --> 05:56.470 C'est vrai. 05:56.470 --> 06:00.010 Désormais, le processus peut simplement invoquer l'appel système select. 06:00.850 --> 06:05.560 Dès que le processus invoque l'appel système select, il est bloqué ici. 06:05.560 --> 06:12.790 Ce processus de réception restera bloqué au niveau de l'appel système select jusqu'à ce qu'un processus d'envoi place les données 06:12.790 --> 06:15.190 dans cette file d'attente de messages. 06:16.150 --> 06:16.810 C'est vrai. 06:16.990 --> 06:24.040 Dans ce cas, l'appel système select ne sera débloqué que lorsque le processus d'envoi placera les données dans la file d'attente 06:24.040 --> 06:24.850 des messages. 06:24.880 --> 06:31.210 Nous vérifions donc ici que c'est bien le descripteur de fichier de la file d'attente des messages qui est activé, n'est-ce 06:31.300 --> 06:32.050 pas ? 06:32.050 --> 06:36.670 Le descripteur de fichier de la file d'attente des messages sera activé lorsqu'un processus d'envoi placera les données dans la file d'attente 06:36.670 --> 06:37.480 des messages. 06:38.530 --> 06:44.740 Cette condition sera vraie lorsque le processus de ponçage aura placé les données dans la file d'attente des messages. 06:44.770 --> 06:50.020 La prochaine chose que doit faire le processus de réception est donc de retirer les données de la file d'attente des messages. 06:50.170 --> 06:57.880 Le retrait des données de la file d'attente des messages s'effectue à l'aide de l'API de réception. 06:57.910 --> 07:03.160 Le processus de réception a lu les données de la file d'attente des messages et les données sont ensuite 07:03.160 --> 07:09.530 copiées dans ce tampon, qui est en fait un tampon vide dans l'espace mémoire fourni par le processus de réception. 07:09.550 --> 07:12.460 Pour copier les données de la file d'attente des messages. 07:14.150 --> 07:20.360 Après avoir retiré les données de la file d'attente des messages, le processus de réception se contente d'imprimer le message 07:20.360 --> 07:22.550 récupéré dans la file d'attente. 07:23.840 --> 07:30.420 Ensuite, le processus de réception retourne à la boucle while one, vide à nouveau la structure de données set, réinitialise 07:30.500 --> 07:37.430 le descripteur de fichier dans la structure de données set et se bloque à nouveau sur l'appel système select. 07:37.430 --> 07:42.680 En d'autres termes, il attend maintenant que le prochain élément de données soit prélevé dans la file d'attente des messages. 07:43.010 --> 07:48.170 Vous pouvez donc constater que le code de l'expéditeur et du processus de réception qui communiquent en utilisant la 07:48.170 --> 07:52.490 file d'attente de messages comme mécanisme de communication inter-processus est assez simple. 07:53.360 --> 07:56.990 Essayons donc d'exécuter ce programme et voyons ce qu'il en est.