Inter-Process Communication Tutorial:
Inter-Process Communication (IPC) refers to a mechanism, where the operating systems allow various processes to communicate with each other. This involves synchronizing their actions and managing shared data. This tutorial covers a foundational understanding of IPC. On modern systems, IPCs form the web that binds together each process within a large scale software architecture.
Let me explain in an example. suppose you are working in a company and you are the team lead where you are responsible for a total project or it is nothing but a job for you which you have to complete it. If you will only working on this project, obviously it will take time for you to complete and also you will be tired of working continuously and also you can’t do perfectly because of no rest. So to complete it you will create a team with some of your team members and divide this work into different sub-modules and each engineer will be responsible for a particular work. which will be easy, efficient, productive, etc.
If we will say in simple, in the above example each work given by each people is nothing but a process. How a human is having its own brain to make a decision as per the direction and memory to store the information. Whenever his boss will ask for anything he can reply with the answer like this a Process is having its own control and memory with execution capability. I hope you have got a basic idea about the process. So let’s go discuss it technically in Linux.
Whenever you will start thinking about the OS or planning to design any software, then everyone started thinking about the Process, Thread, kernel, etc. If you don’t know what is a process, or thread you can go to the Computer science tutorial in my menu and first learn these topics, then you can come to this session. but in a sentence, I can tell a process is a job whereas a thread is a task. First, We will try to understand the Process then we will go to the Inter-Process Communication (IPC).
What Is A Process?
A process is a basic unit of execution in an Operating system. If you are clear about any program that is written in the High-level programming language, then you would have to know about the compilation process. After completion of compilation, We will get an execution file that is nothing but a process. This process can be called by a scheduler to schedule the time when and how to call. So that without any human interpretation the process can do that job. To make it possible for a whole system or to operate a whole system we need an operating system. The main job of an Operating system is to run any number of processes as per the system requirement. The Operating System is responsible from creation to termination of any process.
The processes are typically created in Linux systems by forking from an existing process called a parent process. The Operating System always starts the first init process after bootup. A process can create any number of child processes. After the fork(), the child process will clone the complete image copy of that parent process.
Types of Inter-Process Communication
There are so many processes that are running inside a single system by a single operating system. They all are should be in sync and able to share the information with each other in order to accomplish useful tasks. An Operating System provides several mechanisms to enable the processes to communicate with each other. In the Linux system, all these mechanisms are being implemented in the kernel module. The Linux kernel provides the following IPC mechanisms:
- Signals.
- Anonymous Pipes.
- FIFO.
- SysV Message Queues.
- POSIX Message Queues.
- SysV Shared memory.
- POSIX Shared-memory.
- SysV semaphores.
- POSIX semaphores.
- FUTEX locks.
- Memory-Mapped (File-backed and anonymous shared memory using mmap).
- UNIX Domain Sockets.
- Netlink Sockets.
- Network Sockets.
- Inotify mechanisms.
- FUSE subsystem.
- D-Bus subsystem.
Signals Inter-Process Communication System
The signal is a lightweight Inter-Process Communication system that can communicate between the processes and kernel with each other. The main purpose of this is to notify the processes of events. For example, suppose a user enters Ctrl+Z, an interrupt will generate by a keyboard. The Operating System sends a signal called “SIGINT” to that running process. When that process receives a signal, the normal execution of that process is halted and a separate piece of code nothing but the signal handler will be executed. As a default, a process template having default signal handlers for all the signals. That’s why there is no need to handle the signal handlers for each program in the Linux Operating Systems.
Suppose for example take a Ctrl+Z signal, the process will terminate by default after the user released the key. Even if any program can have its own inbuilt signal handling functions that can be passed to the kernel from application layer with a signal system call function. The Operating will invoke that function when the process receives a signal. It is nothing like will be getting used for a process and kernel communication, it also can be used between a Process and Operating System. It can also be used by a process to communicate with another process within an Operating System. A system call function called a kill(Pid_Id) can be used by a process to send a signal to another process.
(17) D-BUS Inter-Process Communication
The D-BUS is an inter-process communication (IPC) system, providing a simple yet powerful mechanism allowing applications to talk to one another, communicate information, and request services. D-BUS was designed from scratch to fulfill the needs of a modern Linux system. D-BUS’s initial goal is to be a replacement for CORBA and DCOP, the remote object systems used in GNOME and KDE, respectively. Ideally, D-BUS can become a unified and agnostic IPC mechanism used by both desktops, satisfying their needs, and ushering in new features.
D-Bus is a high-level IPC mechanism built generally on top of socket API that provides a mechanism for multiple processes to communicate with each other using various messaging patterns. D-Bus is the specification of a standard for processes communicating with each other and very widely used today by GUI implementations on Linux following Freedesktop.org specifications.
D-BUS, as a full-featured IPC and object system, has several intended uses. First, D-BUS can perform basic application IPC, allowing one process to shuttle data to another—think UNIX domain sockets on steroids. Second, D-BUS can facilitate sending events, or signals, through the system, allowing different components in the system to communicate and ultimately to integrate better. For example, a Bluetooth dæmon can send an incoming call signal that your music player can intercept, muting the volume until the call ends. Finally, D-BUS implements a remote object system, letting one application request services and invoke methods from a different object—think CORBA without the complications.
Why D-BUS Is Unique?
D-BUS is unique from other IPC mechanisms in several ways. First, the basic unit of IPC in D-BUS is a message, not a byte stream. In this manner, D-BUS breaks up IPC into discrete messages, complete with headers (metadata) and a payload (the data). The message format is binary, typed, fully aligned, and simple. It is an inherent part of the wire protocol. This approach contrasts with other IPC mechanisms where the lingua franca is a random stream of bytes, not a discrete message.
Second, D-BUS is bus-based. The simplest form of communication processes to process. D-BUS, however, provides a dæmon, known as the message bus dæmon, that routes messages between processes on a specific bus. In this fashion, bus topology is formed, allowing processes to speak to one or more applications at the same time. Applications can send to or listen to various events on the bus.
A final unique feature is the creation of not one but two of these buses, the system bus, and the session bus. The system bus is global, system-wide, and runs at the system level. All users of the system can communicate over this bus with the proper permissions, allowing the concept of system-wide events. The session bus, however, is created during user login and runs at the user, or session, level. This bus is used solely by a particular user, in a particular login session, as an IPC and remote object system for the user’s applications.
D-BUS Concepts:
Messages are sent to objects. Objects are addressed using path names, such as /org/cups/printers/queue. Processes on the message bus are associated with objects and implemented interfaces on that object.
D-BUS supports multiple message types, such as signals, method calls, method returns, and error messages. Signals are a notification that a specific event has occurred. They are simple, asynchronous, one-way heads-up messages. Method call messages allow an application to request the invocation of a method on a remote object. Method return messages provide the return value resulting from a method invocation. Error messages provide exceptions in response to a method invocation.
D-BUS is fully typed and type-safe. Both a message’s header and payload are fully typed. Valid types include byte, Boolean, 32-bit integer, 32-bit unsigned integer, 64-bit integer, 64-bit unsigned integer, double-precision floating-point, and string. A special array type allows for the grouping of types. A DICT type allows for dictionary-style key/value pairs.
D-BUS is secure. It implements a simple protocol based on SASL profiles for authenticating one-to-one connections. On a bus-wide level, the reading of and the writing to messages from a specific interface are controlled by a security system. An administrator can control access to any interface on the bus. The D-BUS dæmon was written from the ground up with security in mind.
Why D-BUS?
These concepts make nice talk, but what is the benefit? First, the system-wide message bus is a new concept. A single bus shared by the entire system allows for propagation of events, from the kernel (see The Kernel Event Layer sidebar) to the uppermost applications on the system. Linux, with its well-defined interfaces and clear separation of layers, is not very integrated. D-BUS’ system message bus improves integration without compromising fine engineering practices. Now, events such as disk full and printer queue empty or even battery power low can bubble up the system stack, available for whatever application cares, allowing the system to respond and react. The events are sent asynchronously and without polling.
The Kernel Event Layer:
The Kernel Event Layer is a kernel-to-user communication mechanism that uses a high-speed Netlink socket to communicate asynchronously with user-space. This mechanism can be tied into D-BUS, allowing the kernel to send D-BUS signals!. The Kernel Event Layer is tied to sysfs, the tree of objects that lives at /sys on modern Linux systems. Each directory in sysfs is tied to an object, which is a structure in the kernel used to represent objects; sysfs is an object hierarchy exported as a filesystem.
Each Kernel Event Layer event is modeled as though it originated from a sysfs path. Thus, the events appear as if they emit from objects. The sysfs paths are easily translatable to D-BUS paths, making the Kernel Event Layer and D-BUS a natural fit. This Kernel Event Layer was merged into the 2.6.10-rc1 kernel.
Second, the session bus provides a mechanism for IPC and remote method invocation, possibly providing a unified system between GNOME and KDE. D-BUS aims to be a better CORBA than CORBA and a better DCOP than DCOP, satisfying the needs of both projects while providing additional features.
