Originally posted by a user
View Post
Announcement
Collapse
No announcement yet.
D-Bus Implementation Aiming For The Linux Kernel
Collapse
X
-
Originally posted by HyperDrive View PostIf I remember correctly, D-Bus was (still is?) about 17 times *slower* than ORBit (CORBA), so it needs all the help it can get...
Comment
-
Interesting comment...
Originally posted by HyperDrive View PostIf I remember correctly, D-Bus was (still is?) about 17 times *slower* than ORBit (CORBA), so it needs all the help it can get...
That paper examines the performance of various ipc methods for a specific transaction (querying a sqlite db). The methods tested were dbus, dbus with fd passing (what he calls the hybrid approach), a custom ipc socket based approach, and direct sqlite access. As expected direct access was fastest but only by about 20% over dbus with fd and the custom unix socket. So, that doesn't seem too bad.
Comment
-
Originally posted by liam View PostHave a link for that?
Seems rather outdated, though (tests were done on Slackware 10.2, released in 2005), so D-Bus had a lot of time to improve since then.
http://blogs.gnome.org/abustany/2010...of-the-report/
That paper examines the performance of various ipc methods for a specific transaction (querying a sqlite db). The methods tested were dbus, dbus with fd passing (what he calls the hybrid approach), a custom ipc socket based approach, and direct sqlite access. As expected direct access was fastest but only by about 20% over dbus with fd and the custom unix socket. So, that doesn't seem too bad.
Comment
-
Originally posted by HyperDrive View PostSure, here it is: http://eleceng.dit.ie/frank/rpc/CORB...ceAnalysis.pdf.
Seems rather outdated, though (tests were done on Slackware 10.2, released in 2005), so D-Bus had a lot of time to improve since then.
I got quite fast, indeed! File descriptor passing was implemented in 2009 by Lennart Poettering, so that paper I read is obsolete, thankfully.
Thanks for the link, but, as you say, a lot has changed since then.
Honestly I don't know why dbus gets the bad rap. Sure, I wish the commandline tool handled some sort of introspection so I could more easily examine the messages, but this can be done, in principle, and, more importantly, it provides well defined interfaces and is pretty performant.
Comment
-
Originally posted by liam View PostGlad you liked that
Thanks for the link, but, as you say, a lot has changed since then.
Honestly I don't know why dbus gets the bad rap. Sure, I wish the commandline tool handled some sort of introspection so I could more easily examine the messages, but this can be done, in principle, and, more importantly, it provides well defined interfaces and is pretty performant.
It's existence has so led many apps that do not need it to use it, just because it's the official fd.o alternative. Which brings the downside of having to run the unnecessary daemon to users.
It's security and other issues like performance do not concern me; its primary downside to me is the requirement on a daemon. I'm sure others have other reasons to dislike it.
Comment
-
Originally posted by curaga View PostIt's a NIH IPC mechanismAll opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by Ericg View PostOf course its NIH, Gnome and KDE didnt collaborate at all back then so you had KDE with D-Cop which eventually became D-bus, and you had Gnome with ORBit. KDE's solution won out as far as community support
And I am not sure what you mean by "back then", Gnome still doesn't collaborate beyond telling everyone else to do things their way.
Comment
-
Originally posted by TheBlackCat View PostI don't think that is an entirely accurate summary. KDE developed dcop. Rather than adopting KDE's existing technology, Gnome created an incompatible clone of it, then had it declared an fd.o standard. So KDE, trying to be cooperative, abandoned dcop and adopted dbus (dbus at the time was technologically inferior). This seems to be how many fd.o standards come about.
And I am not sure what you mean by "back then", Gnome still doesn't collaborate beyond telling everyone else to do things their way.
10.
How does D-Bus differ from CORBA?
Start by reading Q: 9.
CORBA is designed to support object-oriented IPC between objects, automatically marshalling parameters as necessary. CORBA is strongly supported by the Open Management Group (OMG), which produces various standards and supporting documents for CORBA and has the backing of many large organizations. There are many CORBA ORBs available, both proprietary ORBs and free / open source software ORBs (the latter include ORBit, MICO, and The ACE Orb (TAO)). Many organizations continue to use CORBA ORBs for various kinds of IPC.
Both GNOME and KDE have used CORBA and then moved away from it. KDE had more success with a system called DCOP, and GNOME layered a system called Bonobo on top of CORBA. Without custom extensions, CORBA does not support many of the things one wants to do in a desktop environment with the GNOME/KDE architecture.
CORBA on the other hand has a number of features of interest for enterprise and web application development, though XML systems such as SOAP are the latest fad.
Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems work in terms of objects and methods, and have concepts such as "oneway" calls. Only D-Bus has direct support for "signals" as in GLib/Qt (or Java listeners, or C# delegates).
D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended, because CORBA is more generic and D-Bus has two specific use-cases in mind. This makes D-Bus a bit simpler.
However, unlike CORBA D-Bus does not specify the API for the language bindings. Instead, "native" bindings adapted specifically to the conventions of a framework such as QObject, GObject, C#, Java, Python, etc. are encouraged. The libdbus reference implementation is designed to be a backend for bindings of this nature, rather than to be used directly. The rationale is that an IPC system API should not "leak" all over a program; it should come into play only just before data goes over the wire. As an aside, OMG is apparently working on a simpler C++ binding for CORBA.
Many CORBA implementations such as ORBit are faster than the libdbus reference implementation. One reason is that D-Bus considers data from the other end of the connection to be untrusted and extensively validates it. But generally speaking other priorities were placed ahead of raw speed in the libdbus implementation. A fast D-Bus implementation along the lines of ORBit should be possible, of course.
On a more trivial note, D-Bus involves substantially fewer acronyms than CORBA.
16.
How does D-Bus differ from DCOP?
Start by reading Q: 9.
D-Bus is intentionally pretty similar to DCOP, and can be thought of as a "DCOP the next generation" suitable for sharing between the various open source desktop projects.
D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus should not be more complex for programmers. The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus.
D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though.
At this time, KDE has not committed to using D-Bus, but there have been discussions of KDE bridging D-Bus and DCOP, or even changing DCOP's implementation to use D-Bus internally (so that GNOME and KDE would end up using exactly the same bus). See the KDE mailing list archives for some of these discussions.All opinions are my own not those of my employer if you know who they are.
Comment
Comment