What Is Inter-Process Communication In Linux?

What is a Process?

In an operating system, a process is the fundamental unit of execution. When a high-level programming language program is compiled, an executable file is created, which can be considered a process. This process can be invoked by the scheduler, which determines when and how to execute the process without requiring human intervention. The operating system plays a crucial role in the management and operation of a system since it runs various processes as needed. It handles tasks ranging from process creation to process termination. The primary responsibility of an operating system is to efficiently manage and execute processes based on the system's requirements. In Linux systems, processes are usually created by duplicating an existing process known as the parent process through a mechanism called forking. When a process needs to create a new process, it executes the "fork()" system call. The process that starts the "fork()" is known as the parent process, and the newly created process is known as the child process. After forking, both the parent and child processes continue their execution from the moment of the fork, but they have independent execution spaces and states.

What Is Inter-Process Communication In Linux?

IPC in linux refers to the mechanisms and techniques that allow processes to exchange information, share resources, and communicate with one another. This involves synchronizing their actions and managing shared data. IPC in linux allows processes that are running on the same system to communicate, coordinate, and exchange data. Consider the following scenario: you have a client-server application. The client and server are independent processes that operate on the same Linux system. The client makes requests to the server, which processes the requests and returns responses to the client. This communication can be established via inter-process communication (IPC) mechanisms.

Types of Inter-Process Communication

There are several processes running within a single system by a single operating system. To facilitate this, an operating system offers various mechanisms for inter-process communication (IPC). In Linux, these mechanisms are implemented as part of the kernel module. The Linux kernel has many IPC mechanisms that allow processes to communicate and collaborate. Processes can exchange information and synchronize their actions by using the IPC mechanisms provided by the Linux kernel, enabling efficient and cooperative system operation. Here are some of Linux's inter-process communication (IPC) mechanisms:

1. Signals:
   A signal is a notice to a process that an event has occurred. They are a lightweight form of IPC that can be sent between processes to handle events like process termination or user-defined events.
2. Anonymous Pipes:
   In Linux, anonymous pipes are a type of inter-process communication (IPC) mechanism that allows connected processes to communicate with one another. They offer a one-way data transmission route between processes. The pipe is created by the parent process using the pipe() system call, and it is accessible to both the parent and child processes after forking. The parent process writes data to the pipe's write end, while the child process reads from the read end.
3. FIFO:
   FIFO is a Linux IPC mechanism that allows unrelated processes to communicate with one another. It uses a unique named file as a channel for data exchange. FIFOs are referred to as "named pipes" because they have a unique name in the file system, which serves as their identifier. FIFOs can be created using commands like mkfifo or programmatically with mkfifo() system call.
4. SysV Message Queues:
   SysV Message Queues is a Linux inter-process communication (IPC) mechanism that enables processes to exchange messages via a message queue. The System V message queue is designed for server applications.
5. POSIX Message Queues:
   The abbreviation POSIX stands for Portable Operating System Interface. POSIX message queues are an IPC mechanism that has been provided in Linux since version 2.6.6 (May 2004). It allows processes to exchange data in the form of messages to complete their tasks. The POSIX message queue is designed for use in real-time applications.
6. SysV Shared memory:
   SysV Shared memory enables sharing of memory resources across multiple processes. It allows for the rapid and efficient exchange of massive volumes of data between processes.
7. POSIX Shared-memory:
   POSIX Shared Memory is similar to SysV Shared Memory but corresponds to the POSIX standard. It provides a more adaptable and portable interface for sharing memory between processes.
8. SysV semaphores:
   SysV semaphores are used for process synchronization and mutual exclusion. They enable processes to coordinate access to shared resources by using atomic operations such as wait and signal.
9. POSIX semaphores:
   POSIX semaphores serve the same purpose as SysV semaphores but POSIX semaphore calls are significantly simpler than SysV semaphore calls. POSIX semaphores have been available on glibc-based Linux systems since version 2.6.
10. FUTEX locks:
    FUTEX (Fast User-space Mutex) locks are a lightweight process synchronization mechanism. The fundamental goal is to provide a more efficient mechanism for user-space code to synchronize multiple threads with minimal kernel interaction.
11. Memory-Mapped (File-backed and anonymous shared memory using mmap):
    Memory-mapped IPC enables processes to exchange memory regions mapped to the same file or anonymous memory. It provides a high-performance mechanism for transferring data across processes.
12. UNIX Domain Sockets:
    UNIX Domain Sockets are similar to network sockets but are used for communication between processes on the same machine. UNIX domain sockets support both stream-oriented TCP and datagram-oriented UDP protocols.
13. Netlink Sockets:
    Netlink Sockets is a Linux kernel socket interface that allows inter-process communication between the user-space and the kernel, as well as between multiple user-space processes.
14. Network Sockets:
    Network sockets enable processes to communicate with one another via a network. They provide a common interface for inter-process communication between machines.
15. Inotify mechanisms:
    Inotify mechanisms enable processes to monitor file system events such as file changes, creations, and deletions. They provide a technique for handling file system changes efficiently and reactively.
16. FUSE subsystem:
    FUSE (Filesystem in User-space) subsystem allows users to design customized file systems that are implemented in user space rather than the kernel. It enables flexible and extensible file system communication between user processes and the kernel.
17. D-Bus subsystem:
    D-Bus is a mechanism of inter-process communication (IPC) between processes in Linux and other Unix-like systems. It has a layered structure. D-Bus was particularly designed to fulfill the needs of current Linux systems. It provides a message bus architecture and supports various programming languages and platforms.

Signals Inter-Process Communication System

Signals in Linux allow processes to communicate with one another by sending notifications or triggering specific actions. Consider signals to be messages that processes can send to one another. For example, when a user hits Ctrl+Z, the keyboard generates an interrupt. The operating system then sends a "SIGINT" signal to the running process. When a signal is received, the process temporarily suspends its usual execution and executes a distinct block of code known as the signal handler. In Linux, all signals have a default set of signal handlers, reducing the need to handle them individually for each program. As a result, signals provide a mechanism for processes to respond to system events or interruptions, allowing for effective communication and control.

Consider the Ctrl+Z signal. Normally, when the user releases the key, the process terminates. However, programs can define their special functions to handle such signals. These functions can be communicated to the kernel using a signal system call from the application layer. When a process receives a signal, the operating system will invoke the corresponding special function defined by the program. Signals are not only used for communication between processes and the kernel but they can also be used between a Process and Operating System. Signals are used by processes to communicate with one another. To do this, a system call function named kill(Pid_Id) can be utilized to send a signal from one process to another.

(17) D-BUS Inter-Process Communication

D-Bus is a mechanism of inter-process communication (IPC) between processes in Linux and other Unix-like systems. It has a layered structure. D-Bus was particularly designed to fulfill the needs of current Linux systems. Its major goal was to replace current remote object systems in GNOME and KDE, such as CORBA and DCOP. The goal was to build D-Bus as a universal and neutral interprocess communication (IPC) mechanism that could be used by both desktop environments, responding to their requirements while bringing new features. D-Bus was created to be a complete IPC solution, combining GNOME and KDE communication capabilities and paving the way for enhanced functionality and interoperability.

Uses of D-BUS

D-Bus is a full-featured IPC in linux and object system that can be used for a variety of tasks. Firstly, it supports essential interprocess communication (IPC), which allows processes to communicate data like UNIX domain sockets but with enhanced features. Secondly, D-Bus enables the transfer of events or signals across the system, facilitating enhanced communication and integration between various components. Finally, D-Bus provides a remote object system, which allows an application to request services and call methods from a different object. This feature is similar to CORBA but with less complication.

Features of D-BUS
D-Bus stands out from other IPC mechanisms in a few key ways. Firstly, it operates on discrete messages rather than bytes streams. Each D-Bus message is made up of metadata (headers) and data (payload), resulting in a well-structured binary format. This is in contrast to other IPC mechanisms in which communication is based on arbitrary streams of bytes with no specified message format.

Secondly, D-Bus uses a bus-based system. While direct process-to-process communication is feasible, D-Bus includes a message bus daemon that acts as a central hub for routing messages between processes on a certain bus. This results in the formation of a bus topology in which processes can communicate with one or more applications at the same time.

Finally, D-Bus is distinguished by the existence of two types of buses: system buses and session buses. The system bus is global and covers the whole system, allowing communication between all authorized users. It makes system-wide events and interactions possible. The session bus, on the other hand, is created during a user's login session and is unique to that user. It works at the user level, allowing IPC in linux and remote object system functionality to be adapted to the user's applications.

Why D-BUS?

There are several reasons why D-BUS inter-process communication (IPC) mechanism is used. One reason is that The concept of a system-wide message bus is a novel approach where a single bus is shared by the entire system, enabling events to propagate from the kernel to the highest-level applications. Unlike Linux, which has distinct layers and interfaces, lacking integration, the system message bus of D-Bus enhances integration while upholding sound engineering practices. With this bus, events like disk full, printer queue empty, or low battery power can rise through the system's layers, becoming accessible to any interested application. As a result, the system can adapt and react to these events in real-time. The transmission of events occurs asynchronously and without the need for continuous polling.

The Kernel Event Layer

The Kernel Event Layer serves as a communication mechanism between the kernel and user space, utilizing a high-speed Netlink socket for asynchronous communication. This layer can be integrated with D-Bus, enabling the kernel to send D-Bus signals. The Kernel Event Layer is closely related to sysfs, which depicts a hierarchical tree of objects on current Linux systems that reside in /sys. Each directory in sysfs corresponds to an object structure in the kernel and serves as an object representation. By leveraging this relationship, Kernel Event Layer events are modeled as if they originated from sysfs paths, resembling emitted events from objects. As sysfs paths can be easily translated to D-Bus paths, the Kernel Event Layer and D-Bus naturally complement each other. The 2.6.10-rc1 kernel now includes this Kernel Event Layer. D-Bus' session bus, on the other hand, enables inter-process communication (IPC) and remote method invocation. It aims to develop a unified framework for GNOME and KDE that outperforms CORBA and DCOP. While adding new functionality, D-Bus aims to meet the requirements of both projects.