High-level inter-process communication with D-Bus

Don't Miss the Bus

Article from Issue 282/2024

D-Bus provides a convenient alternative to using traditional Unix inter-process communications such as pipes and sockets.

Programs you run on your Linux desktop often have to communicate with each other. For example, when you open a text file by clicking on it in your file manager, your file manager launches your preferred text editor. However, if you already have open an instance of your text editor, the text editor program as launched by your file manager most likely will request the open instance to open the file in a new tab; then the instance invoked by the file manager will exit. As another example, many laptop computer keyboards have a set of extra keys on or next to the main keyboard for controlling multimedia playback. When pressed, these keys activate a daemon that is part of your desktop environment, and this daemon in turn passes the message on to the most recently opened media player application.

Unix-like operating systems have a number of ways for processes to communicate between each other. Aside from simply passing information in regular files, the most familiar form of inter-process communication (IPC) is the pipe. Pipes are relatively easy to use, but they are only unidirectional, which means a program can send or receive data but cannot do one followed by the other. The other common communications channel is the socket. Sockets are bidirectional, meaning that a program can, for instance, receive a request and then send a reply back to the requesting process. A socket can also be used to communicate with multiple processes at the same time, even processes on a network or over the Internet. The X Window System [1], the most successful and widely-used system for implementing graphical user interfaces on Unix-like systems, uses sockets so that X clients can send requests to an X server and the X server can then send the client back a reply.

But using sockets directly in a program can be cumbersome. A socket simply passes data back and forth between processes; it remains up to the programmer to design a protocol, a format for the messages passed back and forth. This is by no means an insurmountable hurdle, but designing a protocol and writing all the low-level code for sending and receiving these formatted messages via a socket consumes valuable programming time that could be spent elsewhere. Enter D-Bus [2], essentially a layer on top of traditional sockets that takes care of many of the cumbersome and tiring details of sockets. This article will introduce you to D-Bus and explore some practical examples showing D-Bus at work in the Linux environment.


Use Express-Checkout link below to read the full article (PDF).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • D-Bus and HAL

    It’s the end of the line for CORBA! Gnome now relies on the D-Bus messaging system, and KDE is in the process of migrating.

  • Waxing Lyrical

    Whether you listen to music on Spotify or a classic audio player like Rhythmbox, Lollypop, or Audacious, a tool named Lyrics-in-terminal will let you read the lyrics for the track you are currently playing.

  • Hardware Detection

    Udev, HAL, and D-Bus provide automated hardware configuration, even if you plug in on the fly. We'll help you easily access new devices.

  • Udev

    After three years of hanging around on the sidelines, Udev has finally ousted the legacy Dev-FS system. We take a look under the hood at the Udev device management system inside your Linux system.

  • Beagle

    To find files, music, messages, and photos in a single search, try this desktop tool with the power of an Internet search engine.

comments powered by Disqus