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.

[...]