15

When i studied about Linux interprocess Communications, i have known there were some method as: pipe, message queue, socket, signal, shared memory, semaphore and there is no method named Dbus.

But today, when i research about Dbus, i read that: "D-Bus is a system for interprocess communication (IPC)" (See that link: https://en.wikipedia.org/wiki/D-Bus)

So my question is: What is the different between DBus and other IPC methods?

Claudio
  • 10,614
  • 4
  • 31
  • 71
Viet
  • 553
  • 1
  • 4
  • 18

2 Answers2

5

There is no technical, but historical difference.

D-Bus didn't used to be a Linux (i.e. kernel) IPC, but an additional middleware IPC. But in the course of introduction of systemd, D-Bus became for several Linux distributions a part of the basic system.

Matthias
  • 8,018
  • 2
  • 27
  • 53
  • 1
    Thanks. By "middileware IPC" do you mean D-Bus is at a higher IPC level than those https://en.wikipedia.org/wiki/Inter-process_communication? Could you also enumerate some other "middileware IPC" methods? – Tim Dec 19 '18 at 03:34
  • 1
    This is not quite true. While systemd does use D-Bus extensively, D-Bus was already essentially a required component of most free desktop distributions well before systemd was written. They are separate projects. – Philip Withnall Jan 06 '19 at 16:11
  • Sorry, but I can't see what part do you object. The fact that D-Bus was used before systemd, doesn't make it a (kernel) IPC. This is similar to RPC. You will find lots of projects that use RPC. However, the most RPC implementations used to rely on sockets (that in turn is frequently a kernel IPC). – Matthias Jan 07 '19 at 15:49
  • 1
    @Matthias I think the objection is in regards to your characterization of its implied relation to `systemd`, and not about it being kernel-based. The inclusion of D-Bus in popular distros was not dependent upon something to do with `systemd`. Not sure if intended, but implying that it is somehow related to `systemd` feels like it is appealing to some's dissatisfaction with that software and thus intending to cast that onto D-Bus in some way. – Brian Reading Apr 21 '22 at 18:37
4

A one to one ipc method has a large group of cooperating process can cause a dense mesh. But in case of a Dbus each process can connect to any number of process provided with a grant access. On a common single shared channel a user can connect with his own session or a new session without interfering the session of other user. This greatly increase the performance

Refer the link

https://blogs.gnome.org/abustany/2010/05/20/ipc-performance-the-return-of-the-report/

This shows the comparison of the DBus performance against a custom IPC system. You get a better understanding of the performance of the Dbus

Murali Manohar
  • 589
  • 7
  • 35