Quel est le but ftok dans les files de messages

J’ai commencé à lire les files de messages dans l’un des mécanismes IPC sous Linux. Mais au tout début, j’ai quelques questions élémentaires.

  1. Utilisation de ftok() pour générer un identifiant unique (clé) et l’identifiant unique à générer.

  2. Ne pouvons-nous pas utiliser un simple numéro pour obtenir nos clés plutôt que d’utiliser ftok() ?

  3. Quel est le but de la key argument dans la fonction msget ?

     #include "sys/msg.h" key = ftok("/home/beej/somefile", 'b'); msqid = msgget(key, 0666 | IPC_CREAT); 
  4. Quelle est la différence entre msqid et key ?

La fonction ftok crée une sorte d’identifiant à utiliser avec les fonctions System V IPC ( semget , shmget , msgget ). Pensez-y comme à un archiveur de fichiers: lorsque vous ouvrez un fichier, vous passez un chemin pour l’ open et vous obtenez un numéro qui est ensuite utilisé pour la read et l’ write afin d’identifier le fichier. La fonction ftok un objective similaire, mais si la scope du descripteur de fichier est limitée au processus appelé open (et ses enfants), le jeton ftok est valable dans tout le système.

La raison de la scope du système est que vous voulez que deux processus indépendants ou plus aient access aux mêmes ressources IPC. Donc, si vous avez deux programmes, les deux exécutent key = ftok("/home/beej/somefile", 'b'); , les deux auront le même jeton et pourront donc accéder aux mêmes ressources (sémaphores, mémoire partagée, files de messages). C’est tout l’intérêt de la communication inter-processus.

Vous ne pouvez pas simplement utiliser un “nombre simple”, car vous ne savez pas si le jeton peut être, par exemple, un index d’une table interne au système ou quelque chose de ce genre. En d’autres termes, vous ne savez pas comment ce jeton est utilisé en interne, vous devez donc utiliser ftok .

La page de manuel indique: “Le chemin spécifié doit spécifier un fichier existant accessible au processus appelant, sinon l’appel échouera. Notez également que les liens vers les fichiers renverront la même clé, avec le même identifiant.” À partir de là, je suppose qu’au moins certaines implémentations ftok créent le jeton en recherchant le numéro d’inode du fichier spécifié par chemin et le combinent avec le deuxième argument pour créer le jeton. Le deuxième argument existe simplement pour vous permettre de créer un ensemble de ressources IPC (comme plusieurs sémaphores pour protéger différentes ressources).

En ce qui concerne la différence entre key_t (la valeur renvoyée par ftok ) et la valeur conservée par msgget : la première vous donne access à un ensemble de ressources IPC (sémaphore, mémoire partagée et queue de messages), tandis que la dernière identifie une queue de messages spécifique.

  1. Je ne comprends pas tout à fait votre question, mais elle génère un identifiant unique pour le système (non processus) basé sur le chemin du fichier indiqué. Cet identifiant unique (lié au chemin) permet à différents processus de se lier à la même file de messages.

  2. Oui, vous pourriez, s’ils l’ont conçu de cette façon. Mais un chemin de fichier est un moyen plus universel d’arriver à un mécanisme de génération de clé déterministe commun auquel plusieurs processus peuvent facilement accéder.

  3. Voir 1 & 2

  4. msqid est analogue à un descripteur de fichier, dans lequel vous pouvez envoyer et recevoir des messages à ce descripteur. La clé est ce qui vous permet d’associer votre hook à la file de messages qui vous intéresse. Comme analogie, si la clé est un chemin de fichier dans le système de fichiers global, alors le msqid serait le pseudonyme de votre processus pour la lecture / écriture sur celui-ci. .

  1. Quoi?

  2. Cela pourrait fonctionner, mais lequel choisiriez-vous et qui garantit que les autres programmes (ou le système lui-même) n’utiliseront pas les mêmes numéros? Cela conduirait à la confusion.

  3. L’objective est de fournir une valeur unique à l’échelle du système afin d’identifier une file de messages. Comme l’indique la page de manuel,

    Généralement, une tentative dans la mesure du possible combine l’octet proj_id donné, les 16 bits inférieurs du numéro d’inode et les 8 bits inférieurs du numéro de périphérique en un résultat de 32 bits. Des collisions peuvent facilement se produire, par exemple entre des fichiers sur / dev / hda1 et des fichiers sur / dev / sda1.

    Donc, il faut juste un fichier et calcule un ID à partir duquel on sait qu’un autre programme utilisant le même fichier et ID de projet obtiendra le même résultat.

  4. key est juste un identifiant unique qui peut être utilisé à d’autres fins, tandis que msqid est l’ID (type de msqid ) d’une queue réellement existante.