Announcement

Collapse
No announcement yet.

D-Bus Implementation Aiming For The Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Interesting comment...

    Originally posted by HyperDrive View Post
    If I remember correctly, D-Bus was (still is?) about 17 times *slower* than ORBit (CORBA), so it needs all the help it can get...
    Have a link for that?
    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


    • #42
      Originally posted by liam View Post
      Have a link for that?
      Sure, 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.
      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.
      I got quite fast, indeed! File descriptor passing was implemented in 2009 by Lennart Poettering, so that paper I read is obsolete, thankfully.

      Comment


      • #43
        Originally posted by HyperDrive View Post
        Sure, 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.
        Glad 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.

        Comment


        • #44
          Originally posted by liam View Post
          Glad 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 a NIH IPC mechanism that has many downsides (weird protocol, requires a daemon) while most of its users do not make use of its strengths (multicast simpler than via networking).

          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


          • #45
            I fail twice with its vs it's, good indication that it's a morning

            Comment


            • #46
              Originally posted by curaga View Post
              It's a NIH IPC mechanism
              Of 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

              Comment


              • #47
                Originally posted by Ericg View Post
                Of 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
                I 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.

                Comment


                • #48
                  Originally posted by TheBlackCat View Post
                  I 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.
                  Dbus FAQ:


                  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.
                  Sounds like dbus is more dcop than bonobo/ORBIT/Cobra

                  Comment


                  • #49
                    Originally posted by curaga View Post
                    It's a NIH IPC mechanism that has many downsides (weird protocol, requires a daemon) while most of its users do not make use of its strengths (multicast simpler than via networking).

                    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.
                    Are you calling it NIH b/c of dcop, or were you a fan of corba?
                    What's wrong with the protocol? What's wrong with a daemon (addmittedly I'm not super excited that we need two instances running but it's not that big of an issue)?
                    Your point about misuse is well taken, but that is more the fault of application/framework developers. Can't blame the bread makers if someone decides to build a house out of their product.

                    Comment


                    • #50
                      Trivia: From what I've read, D-Bus is pretty close to ToolTalk, which is the message-passing part of CDE. ToolTalk runs on top of Sun or DCE RPC (glibc2 includes sunrpc, and tirpc is another version of the same).

                      One criticism of dbus I remember hearing is that it's pretty much reinventing an RPC system (in the name of IPC), when there are already several ones out there. I wouldn't be qualified to verify that, though. Another line is that it's "over-engineered" and needlessly complex.

                      Considering curaga's involvement (Tiny Core Linux), I suspect he's looking at it from the aspect of bloat.
                      When you're dealing with a distro that runs on a 486 with ~48 MB RAM and the CD is 12MB, extra daemons look a lot more wasteful than they do for an average Ubuntu or Fedora user.

                      Comment

                      Working...
                      X