Xsi IPC for Process Communication

1. xsi IPC

1.1 identifier and key

There are three types of IPC called xsi IPC, namely message queue, semaphores, and shared memory.

The IPC structure (message queue, semaphore, and shared storage) in each kernel is referenced with a non-negative integer identifier (identifier. For example, to send or retrieve a message to a message queue, you only need to know its queue identifier. When an IPC structure is created and deleted later, the identifier associated with this structure is continuously added with 1 until it reaches the maximum value of an integer and then returns to 0.

The identifier is the internal name of the IPC object. The key is the external name of the IPC object. Specify a key whenever you create an IPC structure (call msgget, semget, or shmget. The key data type is the basic system data type key_t, which is usually defined as a long integer in <sys/types. h>. The key is changed from the kernel to the identifier.

The customer process and server process recognize a path name and Project ID (the project ID is 0 ~ Between 255 characters), and then call ftok to convert the two values into a key. Use this key to create a new IPC structure or obtain an IPC structure. The unique service provided by ftok is that a path name and Project ID generate a key.

# Include <sys/IPC. h>

Key_t ftok (const char * path, int ID );

The path parameter must reference an existing file. When a key is generated, only eight lower bits of the ID parameter are used.

The three get functions (msgget, semget, and shmget) both have two similar parameters: a key and an integer flag. If one of the following conditions is met, a new IPC structure is created:

1). The key is ipc_private;

2). The key is not currently combined with the IPC result of a specific type, and the ipc_creat bit is specified in the flag.

To access an existing Queue (usually a client process), the key must be the key specified when the queue is created, and ipc_creat should not be specified.

If you want to create a new IPC structure and make sure that you do not reference an existing IPC structure with the same identifier, you must specify both the ipc_creat and ipc_excl bits in the flag. In this way, if the IPC structure already exists, an error occurs and eexist is returned.

1.2. Permission Structure

Xsi IPC sets an ipc_perm structure for each IPC structure. This structure specifies the permission and owner.

Struct ipc_perm {

Uid_t uid; // owner's valid user ID

Gid_t GID; // owner's valid group ID

Uid_t cuid; // creator's valid user ID

Gid_t cgid; // creator's valid group ID

Mode_t mode; // Access Modes

.

.

.

};

For a complete definition of the system you are using, see <sys/IPC. h>.

When creating an IPC structure, the initial values are attached to all fields. Call msgctl, semctl, or shmctl to modify the UID, GID, and mode fields. To change these values, the calling process must be the creator or super user of the IPC structure. Changing these fields is similar to calling chown and chmod in a file.

The value of the field mode is as follows, but there is no execution permission for any IPC structure. In addition, message queues and shared memory use the terms read and write, while semaphores use the terms rend and alter ).

Permission	Bit
User Read (change)	0400
User Write	0200
Group read	0040
Group write (change)	0020
Other reads	0004
Other writes (changes)	0002

1.3. structure restrictions

All three forms of xsi IPC have built-in limitations (built-in limit ). Most of these restrictions can be changed by reconfiguration the kernel.

1.4. Advantages and Disadvantages

The main problem with xsi IPC is that the IPC structure works within the system and there is no access count. For example, if a process creates a message queue, a few messages are put in the queue and then terminated, but the message queue and its content are not deleted. They remain in the system until a process calls msgrcv or msgctl to read or delete a Message Queue; or a process executes the ipcrm command to delete the Message Queue; or, the system is starting to delete the message queue. Compared with pipelines, when the process of the last access pipeline stops, the pipelines are completely deleted. For FIFO, when the last process that references FIFO ends, its name remains in the system until it is explicitly deleted, however, the data left in the FIFO is deleted at this time.

Another problem with xsi IPC: These IPC structures have no names in the file system and have to add new commands IPCS and ipcrm.

Because these xsi IPC do not use file descriptors, they cannot use multi-channel I/O functions: select and poll. This makes it difficult to use multiple IPC structures at a time, and use the IPC structure in files or device I/O. For example, without some form of busy-waiting loop, a server process cannot wait for messages to be placed in either of the two message queues.