进程间通信之XSI IPC

XSI IPC源自于系统V的IPC功能。

有三种IPC我们称作XSI IPC，即消息队列、信号量以及共享存储器，它们之间有很多相似之处。

1、标识符和键

每个内核中的IPC结构（消息队列、信号量或共享存储段）都用一个非负整数的标识符（identifier）加以引用。例如，为了对一个消息队列发送或取消息，只需要知道其队列标识符。与文件描述符不同，IPC标识符不是小的整数。当一个IPC结构被创建，以后又被删除时，与这种结构相关的标识符连续加1，直到达到一个整型数的最大正值，然后又回转到0.

标识符是IPC对象的内部名。为使多个合作进程能够在同一IPC对象上会合，需要提供一个外部名方案。为此使用了键（key），每个IPC对象都与一个键相关联，于是键就用作为该对象的外部名。

无论何时创建IPC结构（调用msgget、semget或shmget），都应指定一个键，键的数据类型是基本系统数据类型key_t，通常在头文件<sys/types.h>中被定义为长整型。键由内核变换成标识符。

有多种方法使客户进程和服务器进程在同一IPC结构上会合：

（1）服务器进程可以指定键IPC_PRIVATE创建一个新IPC结构，将返回的标识符存放在某处（例如一个文件）以便客户进程取用。键IPC_PRIVATE保证服务器进程创建一个新IPC结构。这种技术的缺点是：服务器进程要将整型标识符写到文件中，此后客户进程又要读文件取得此标识符。

IPC_PRIVATE键也可以用于父、子进程关系。父进程指定IPC_PRIVATE创建一个新IPC结构，所返回的标识符在调用fork后可由子进程使用。接着，子进程又可将此标识符作为exec函数的一个参数传给一个新程序。

（2）在一个公用头文件中定义一个客户进程和服务器进程都认可的键。然后服务器进程指定此键创建一个新的IPC结构。这种方法的问题是该键可能已与一个IPC结构相结合，在此情况下，get函数（msgget、semget或shmget）出错返回。服务器进程必须处理这一错误，删除已存在的IPC结构，然后试着再创建它。

（3）客户进程和服务器进程认同一个路径名和项目ID（项目ID是0-255之间的字符值），接着调用函数ftok将这两个值变换为一个键。然后在方法（2）中使用此键。ftok提供的唯一服务就是由一个路径名和项目ID产生一个键。

#include <sys/ipc.h>
key_t ftok(const char *path, int id);
返回值：若成功则返回键，若出错则返回（key_t）-1

path参数必须引用一个现存文件。当产生键时，只是用id参数的低8位。

ftok创建的键通常是下列方式构成的：按给定的路径名取得其stat结构（http://www.cnblogs.com/nufangrensheng/p/3501385.html），从该结构中取出部分st_dev和st_ino字段，然后再与项目ID组合起来。如果两个路径名引用两个不同的文件，那么，对这两个路径名调用ftok通常返回不同的键。但是，因为i节点号和键通常都存放在长整型中，于是创建键时可能会丢失信息（？）。这意味着，如果使用同一项目ID，那么对于不同文件的两个路径名可能产生相同的键。

三个get函数（msgget、semget和shmget）都有两个类似的参数：一个key和一个整型flag。如若满足下列两个条件之一，则创建一个新的IPC结构（通常由服务器进程创建）：

• key是IPC_PRIVATE；
• key当前未与特定类型的IPC结构相结合，并且flag中指定了IPC_CREAT位。

为访问现存的队列（通常由客户进程进行），key必须等于创建该队列时所指定的键，并且不应指定IPC_CREAT。

注意，为了访问一个现存队列，决不能指定IPC_PRIVATE作为键。因为这是一个特殊的键值，它总是用于创建一个新队列。为了访问一个用IPC_PRIVATE键创建的现存队列，一定要知道与该队列相结合的标识符，然后在其他IPC调用中（例如msgsnd和msgrvc）使用该标识符。

如果希望创建一个新的IPC结构，而且要确保不是引用具有同一标识符的一个现行IPC结构，那么必须在flag中同时指定IPC_CREAT和IPC_EXCL位。这样做了以后，如果IPC结构已经存在就会造成出错，返回EEXIST（这与指定了O_CREAT和O_EXCL标志的open相类似）。

2、权限结构

XSI IPC为每一个IPC结构设置了一个ipc_perm结构。该结构规定了权限和所有者。它至少包括下列成员：

struct ipc_perm {
    uid_t    uid;     /* owner's effective user id */
    gid_t    gid;     /* owner's effective group id */
    uid_t    cuid;    /* creator's effective user id */
    gid_t    cgid;    /* creator's effective group id */
    mode_t   mode;    /* access modes */
    ...
};

每种实现在其ipc_perm结构中会包括另外一些成员。如欲了解你所用系统中它的完整定义，请参见<sys/ipc.h>。

在创建IPC结构时，对所有字段都赋初值。以后，可以调用msgctl、semctl或shmctl修改uid、gid和mode字段。为了改变这些值，调用进程必须是IPC结构的创建者或超级用户。更改这些字段类似于对文件调用chown和chmod。

mode字段的值类似于http://www.cnblogs.com/nufangrensheng/p/3502097.html中表4-5所示的值，但是对于任何IPC结构都不存在执行权限。另外，消息队列和共享存储使用术语读（read）和写（write），而信号量则使用术语读（read）和更改（alter）。表15-2中对每种IPC说明了6种权限。

某些实现定义了表示每种权限的符号常量，但是这些常量并不包括在Single UNIX Specification中。

3、结构限制

三种形式的XSI IPC都有内置限制（built-in limit）。这些限制的大多数可以通过重新配置内核而加以更改。

在报告和修改限制方面，每种平台都提供它自己的方法。FreeBSD 5.2.1、Linux 2.4.22和Mac OS X 10.3提供了sysctl命令，用该命令观察和修改内核配置参数。Solaris9修改内核配置参数的方法是，修改文件/etc/system，然后重新启动。

在Linux中，你可以运行 ipcs -l以显示IPC相关的限制。

4、优点和缺点

XSI IPC的主要问题是：IPC结构是在系统范围内起作用的，没有访问计数。例如，如果进程创建了一个消息队列，在该队列中放入了几条消息，然后终止，但是消息队列及其内容并不会被删除。它们余留在系统中直至出现下述情况：由某个进程调用msgrcv或msgctl读消息或删除消息队列；或某个进程执行ipcrm（1）命令删除消息队列；或由正在再启动的系统删除消息队列。将此与管道相比，当最后一个访问管道的进程终止时，管道就被完全地删除了。对于FIFO而言，虽然当最后一个引用FIFO的进程终止时其名字仍保留在系统中，直至显示地删除它，但是留在FIFO中的数据却在此时全部被删除，于是也就徒有其名了。

XSI IPC的另一个问题是：这些IPC结构在文件系统中没有名字。我们不能用文件I/O和文件和目录章节中所述的函数来访问它们或修改它们的特性。为了支持它们不得不增加了十几条全新的系统调用（msgget、semop、shmat等）。我们不能用ls命令见到IPC对象，不能用rm命令删除它们，也不能用chmod命令更改它们的访问权限。于是，就不得不增加新的命令ipcs（1）和ipcrm（1）。

因为这些IPC不使用文件描述符，所以不能对它们使用多路转接I/O函数：select和poll。这就使得难于一次使用多个IPC结构，以及在文件或设备I/O中使用IPC结构。

表15-3对不同形式IPC的某些特征进行了比较。

                                         表15-3 不同形式IPC之间的特征比较

表15-3中的“无连接”指的是无需先调用某种形式的打开函数就能发送消息的能力。正如前述，因为需要有某种技术以获得队列标识符，所以我们并不认为消息队列具有无连接特性。因为所有这些形式的IPC都限制在单主机上，所以它们都是可靠的。当消息通过网络传送时，丢失消息的可能性就要加以考虑。“流控制”指的是：如果系统资源（缓冲区）短缺或者如果接收进程不能再接收更多消息，则发送进程就要休眠。当流控制条件消失时，发送进程应自动被唤醒。

表15-3中没有表示的一个特征是：IPC设施能否自动地为每个客户进程创建一个到服务器进程的唯一连接。STREAMS以及UNIX流套接字可以提供这种能力。