BIND 10 #849: DBus as possible replacement of MSGQ.

[BIND 10 Development]

#849: DBus as possible replacement of MSGQ.
-------------------------------------+-------------------------------------
                 Reporter:  vorner   |                Owner:  stephen
                     Type:  task     |               Status:  reviewing
                 Priority:  major    |            Milestone:
                Component:           |  Sprint-20110419
  Unclassified                       |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  0.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => stephen


Comment:

 Hello

 Replying to [comment:4 stephen]:
 > '''Licence'''[[BR]]

 Well, it depends. We don't really want to distribute dbus ourself, do we?
 Just dynamically link libdbus (and it would be the same thing authors of
 proprietary extensions would do as well, I guess). Anyway, one of the
 first users of dbus was Skype, which has one of the worst proprietary
 licences. And they linked libdbus statically into their binary. Of course,
 they did not bundle dbus-monitor or any of these with it.

 > '''Bindings'''[[BR]]
 > Regarding the C++ bindings, D-Bus is written in C so it should not be an
 insurmountable problem to create a useful interface layer in C++.
 However, the documentation does warn "If you use this low-level API
 directly, you're signing up for some pain" which may indicate that coding
 our own binding in C++ will be far from straight forward.

 As far as I understand this, in python, Qt, or whatever, you just say
 something like „This object is to be exported, these are the methods that
 should be exported“ and the bindings handle the rest.

 With the libdbus, you actually need to know what kind of messages go over
 the wire, provide a callback where you get a message requesting running a
 method `m` on object `x.y.z` with parameter `42` and it's up to you to
 decide where do you get the x.y.z object, how to call it's method or what
 is an object anyway. But it'll handle marshalling the data structures that
 are sent, it will be able to connect, etc.

 So, there is a gaph between them and it wouldn't be straight-forward (and
 we might try to have a look at some of the abandoned bindings to have a
 starting point, or something, maybe), but I think for our needs, something
 simple would be enough (we don't really need to be able to create proxy
 objects with full introspection of the remote end, etc).

 > '''Miscellaneous'''[[BR]]
 >  * I'd see the real blocker in the use of D-Bus as being how important
 cross-machine communication is.  TCP support appears to be very limited -
 two quotes from the D-Bus web pages are:
 >    - "Currently the communicating applications are on one computer, or
 through unencrypted TCP/IP suitable for use behind a firewall with shared
 NFS home directories."
 >    - "The TCP/IP transport isn't tested in use and it has the problems
 of access control, lack of encryption, and inability to go through
 firewalls and NAT."

 Yes, and it's because there was no need for this on their side ‒
 freedesktop and dbus is mostly interested in desktop usage. So they go as
 far as they need ‒ some people have multiple computers with shared home,
 so they can have shared dbus for multiple logins. Nobody really needed
 encryption or some real ACL (except for the basic allowed/not allowed to
 connect ‒ note that DBus has the ability to do full ACLs on per-message
 basis, so the missing ACL would mostly mean they can't do the ACLs based
 on IP address, etc, once the connection is made, the connectee is fully
 trusted as local). It might be a worthwhile idea to persuade someone that
 he really wants to have his Empathy running across multiple computers that
 aren't on the same LAN and have him write it >:-).

 The fact that windows version uses TCP/IP over localhost makes me think
 the data go well over the connection, so the only need would be to place
 some better authentication in front of the connection and wrap it into
 encryption. Traversal trough NAT, is it really a problem for us? Can't we
 expect all the clustering machines would see each other?

 Anyway, how much do we need from it? If we didn't need encryption (and
 said that if the clustering servers are in different locations, the admin
 should use vpn or something), it might be more or less enough. Because,
 from dbus-daemon manpage, about how it can listen:

 {{{
 Example: <listen>unix:path=/tmp/foo</listen>
 Example: <listen>tcp:host=localhost,port=1234</listen>
 }}}

 and about authentication to connect:

 {{{
 Example: <auth>EXTERNAL</auth>
 Example: <auth>DBUS_COOKIE_SHA1</auth>
 }}}

 Should I try some experiments with it?

 Anyway, it sounds like better state than current msgq has ‒ we don't
 really have any authentication, do we? And we aren't able to listen on
 TCP.

 And if it really was a problem, we could do a small hack ‒ create a bridge
 application, that would sign for all signals, on local dbus, presented all
 objects from the remote end on it's connection and used the libdbus in
 one-to-one mode to connect with the bridge on the other side and forward
 it in between.

 > For these reasons, I'd be keen to see if something else is better before
 making a decision to go with this one.

 Agreed, I'm going to have a look at more options. We really want the best
 thing available ;-).

-- 
Ticket URL: <http://bind10.isc.org/ticket/849#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development