Whats is purpose ftok in Message queues

Question

I have started reading message queues one of the IPC mechanism on Linux .But at very first step I have some very basic questions.

1. Use of ftok() to generate unique ID (key) and what is unique ID which is to be generated.

2. Can't we use simple a number to get our keys rather than using ftok()?

3. What is the purpose of the argument key in the msget function?

   #include "sys/msg.h"
   key = ftok("/home/beej/somefile", 'b');
   msqid = msgget(key, 0666 | IPC_CREAT);
   

4. What is the difference between msqid and key?

Answer 1

The ftok function creates a sort of identifier to be used with the System V IPC functions (semget, shmget, msgget). Think of it like a filedescriptor: when you open a file, you pass a path to open and get a number in return that is then used for read and write to identify the file. The ftok function serves a similar purpose, but while the filedescriptor's scope is limited to just the process that called open (and its children), the ftok token is valid across the system.

The reason for the system scope is that you want two or more independent processes to have access to the same IPC resources. So if you have two programs, both of which execute key = ftok("/home/beej/somefile", 'b');, both will get the same token and can therefor access the same resources (semaphores, shared memory, message queues). That's the whole point of Inter Process Communication.

You cannot just use a "simple number" as you don't know whether the token might be for example an index to an system-internal table or something. In other words, you don't know how that token is used internally so you do need to use ftok.

The man page says: "The specified path must specify an existing file that is accessible to the calling process or the call will fail. Also, note that links to files will return the same key, given the same id." From this I assume that at least some ftok implementations create the token by looking up the inode number of the file specified by path and combine it with the second argument to create the token. The second argument exists simply so you can create a bunch of IPC resources (like several semaphores to protect different resources).

As for the difference of key_t (the value returned by ftok) and the value retured by msgget: the former gives you access to a bunch of IPC resources (semaphore, shared memory and message queue), while the later identifies a specific message queue.

Answer 2

1. I don't fully understand your question, but it generates a unique identifier to the system (not process) based on the file path given. This unique identifier (tied to path) allows different processes to bind to the same message queue.

2. Yes, you could, if they designed it that way. But a file path is a more universal way of arriving at a common deterministic key generation mechanism that multiple processes can easily access.

3. See 1 & 2

4. msqid is analogous to a file handle, that you can send and receive messages to that handle. The key is what allows you to associate your hook into the message queue your interested in. As an analogy, if the key is to a file path in the global file system, then the msqid would be your process's handle to read/write to it.

Answer 3

1. What?

2. That could work, but which one would you choose and who guarantees that other programs (or the system itself) won't use the same numbers? That would lead to confusion.

3. The purpose is to provide a system-wide unique value in order to identify a message queue. As the manpage states,

   Typically, a best effort attempt combines the given proj_id byte, the lower 16 bits of the inode number, and the lower 8 bits of the device number into a 32-bit result. Collisions may easily happen, for example between files on /dev/hda1 and files on /dev/sda1.

   So it just takes a file and calculates an ID from which is known that another program using the same file and project ID will get the same result.

4. key is just an identifier which is unique but can used for other purposes, while msqid is the ID (kind of handle) for a really existing queue.