Unix Prog: XSI IPC Overview

1. XSI IPC
Three types of XSI IPC: message queue, semaphores, and shared memory.
All three objects share some similarities as following.

2. Identifiers and Keys
Each IPC structure(message queue, semaphores, and shared memory) is identified in the kernel by a non-negative integer. To send or fetch a message to or from a message queue, we need to know the identifier for the message queu.

Each IPC structure is associated with a key that acts as an external name, compared to identifier, which is internal name. Whenever an IPC structure is being created(msgget, semget, or shmget), a key must be specified.

Several ways for clients and server to rendezvous at the same IPC structure:
1) The server can create a new IPC structure by specifying a key of IPC_PRIVATE and store the returned identifier somewhere, like a file, for the client to obtain
2) The server create a new IPC structure using IPC_PRIVATE Key, then the resulting identifier is available to the child after the fork.
3) The client and the server can agree on a key by defining the key in a common header. The server then creates a new IPC structure specifying this key. If the key is already associated with one existing IPC structure, the server need to delete that structure and re-create it.
4) The client and server can agree on a pathname and project id(between 0 and 255), and call the function ftok to convert these two values into a key.

System Definition:

 ubuntu@ip-172-31-23-227:~$ less /usr/include/x86_64-linux-gnu/sys/ipc.h  
 ......  
 /* Generates key for System V style IPC. */  
 extern key_t ftok (const char *__pathname, int __proj_id) __THROW;  
 ......  

3. Create and Get the IPC Structure
For 3 get functions: msgget, semget, and shmget, all need to specify a key and an integer flag.

Create the IPC Structure with key IPC_PRIVATE:
1) After server create the IPC structure with key IPC_PRIVATE, then it is not possible to be conflict with any existing structure, since it would create a new structure.
2) When client want to refer to this structure, for example, sending a message to the message queue, the client must know the identifier of this structure.

Create the IPC Structure with a key who is not currently associated with an IPC structure of the particular type and the IPC_CREAT bit of flag is specified.
1) In this case, when client want to refer to this IPC structure, it need to specify the same key type without specifying IPC_CREAT bit flag.

Create the IPC Structure with both IPC_CREAT and IPC_EXCL bits set:
If the specified key refer to some existing IPC structure, , it will return an error of EEXIST.

4. Permission Structure
XSI IPC associates ipc_perm structure with each IPC structure:
System Definition:

 ubuntu@ip-172-31-23-227:~$ less /usr/include/x86_64-linux-gnu/bits/ipc.h  
 ......  
 /* Data structure used to pass permission information to IPC operations. */  
 struct ipc_perm  
  {  
   __key_t __key;           /* Key. */  
   __uid_t uid;            /* Owner's user ID. */  
   __gid_t gid;            /* Owner's group ID. */  
   __uid_t cuid;            /* Creator's user ID. */  
   __gid_t cgid;            /* Creator's group ID. */  
   unsigned short int mode;      /* Read/write permission. */  
   unsigned short int __pad1;  
   unsigned short int __seq;      /* Sequence number. */  
   unsigned short int __pad2;  
   __syscall_ulong_t __glibc_reserved1;  
   __syscall_ulong_t __glibc_reserved2;  
  };  
 ......  

All above fields are initialized when IPC structure is created, at a later time, we can modify the uid, gid, and mode fields by calling msgctl, semctl, or shmctl.  And the caller must be either the creator of the IPC structure or the super user.

mode member represents the permission bits. In IPC permission structure, only 6 bits are specified:
1) user read 2) user write 3) group read 4) group write 5) other read 6) other write

5. Advantages and Disadvantages:
1) IPC structure is system wide and do not have one reference count. If we create a message queue, place some messages on the queue, and then terminate, the message queue and its contents are not deleted.
For pipe, when the last process to reference it terminates, the data in there is completely removed.
For FIFO, although the file stays in the file system. But any data left in a FIFO is removed when the last process to reference FIFO terminates.

2) IPC structure is not known by names in the file system, we can't access them and modify their properties with the standard I/O functions

3) These forms of IPC don't use file descriptors, we can't use the multiplexed I/O functions(select and poll) with them.