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

[BIND 10 Development]

#849: DBus as possible replacement of MSGQ.
-------------------------------------+-------------------------------------
                 Reporter:  vorner   |                Owner:  UnAssigned
                     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 => UnAssigned
 * status:  new => reviewing


Comment:

 So, I discovered it might be usable, with some work.

 '''Licence''':
 The core dbus (libdbus and dbus-daemon) have two licences (we can choose
 which one we use), GPL and some AFL. The AFL, according to what they
 claim, it is somehow more wordy MIT or BSD licence. Their FAQ says the
 code can be used in closed-sourced application, that it only forbids suing
 them around patents while still using their code. So, while I'm not a
 lawyer, my impression is this could be compatible.

 Python bindings has some licence in the sense „you can do everything, only
 include the no-warranty disclaimer“, which we do anyway.

 I looked for some C++ bindings of the low-level libdbus, but they are
 either abandoned, single-man show toolkit-based or GPL, so we would
 probably need to wrap around libdbus ourself. The libdbus is something
 that is meant to be integrated into something, they say it can be plugged
 into whatever mainloop or so, but it is really low-level.

 '''Dependencies''':
 None for the libdbus, the dbus-daemon needs xml parser to read
 configuration (it is happy with either expat or libxml).

 The python bindings need glib (either a new one, that includes dbus
 support in itself, or older and glib-dbus bindings). I don't know how big
 problem that is, but maybe the people who don't want glib on their system
 would be the same as those not wanting python there.

 '''Platforms, stability, testing''':
 They say they run on anything UNIX-like (quick google query for solaris
 dbus showed some minor bugs, like it wants to be root if it should be the
 system message bus, so I deduce it runs there, we would run our own
 instance anyway). It seems quite widely used, both KDE and GNOME use it,
 most linux distros rely on the system daemon for all the new fancy hal
 daemons, bluetooth support, etc. The documentation claims they are one of
 the best OSS project regarding test coverage.

 The windows port is merged into the main release for some time now and it
 is used over 3 years for KDE on windows, but they say some of the tests
 weren't ported to windows yet.

 I guess it doesn't provide a mock class for testing.

 '''Misc''':
 They use TCP connections on windows, so the communication is possible over
 something non-UNIX-socketish, but remote connection isn't implemented yet.
 They use some cookie for authentication. So, running over multiple
 machines would need some work (I didn't ask on the ML yet, this could be
 one of the questions).

 They have a data type to send an unix file descriptor. It might error on
 sending it, if the connection or daemon doesn't support it, but it should
 work for „common“ unix scenario. Windows and cross-machine might be
 problem.

 I did run multiple instances of dbus some time ago, and the dbus-daemon
 can be passed a different configuration file (instead of `--system` or
 `--session`) to start another daemon. It would just provide the
 environment variables needed for connecting to it.

 Performance is hard to guess from what is found on the internet. However,
 they compare it with raw socket (I found 2.5 slower than passing trough
 raw socket, but then they rewrote some marshalling and validating of data
 since then, so it probably changed), other compared it with CORBA and said
 it was slightly slower. But that sounds like reasonable performance,
 really better than our python msgq implementation. And all their
 communication can be asynchronous, which helps real-life speed as well.

 It is possible to declare types and public functions/interfaces, etc. to
 help some bindings and generating remote proxy objects, but it seems not
 to be mandatory.

 '''Design''':
 Each application gets an unique address at connection, which is never
 reused. An application might claim a nickname (so we could have a config
 manager that would be called a config manager, no matter which address it
 got).

 The system is somehow objectish, so an application might provide an object
 (or more of them, but currently it seems we would have single object per
 module) with methods (similar like our commands) and signals. There are
 also some interfaces which are implemented by objects (I didn't really
 read the documentation to depth, though, but this might turn out to ask
 for provided function signatures ‒ but we can use some variant or
 something generic enough) that state which methods are available on the
 object.

 So, for example, for configuration, we would have an object that would be
 the configuration (in the manager) and it would have a method to provide
 the configuration values.

 The signals are kind of broadcast. An object may emit signal to inform the
 world about something. Anybody is allowed (well, there can be some ACLs in
 the config file) to subscribe for notification of signal (or provide some
 pattern which signals to subscribe). So it's slightly inverse of what we
 have. In the example with configuration, it would have a signal
 „configuration changed“ (and it could carry the data as well).

 '''Conclusion''':
 I see a way how to replace the msgq by dbus, which would have some
 advantages and disadvantages:
  * It has slightly different semantics, so we would need to modify the
 code a little bit (for example the inverse broadcasts)
  * It would require nontrivial amount of work (for example wrapping the
 libdbus for our needs, and, in future, probably implementing some kind of
 bridge between two dbuses across network, modifying some communication
 logic slightly, work around the need to provide interfaces).
  * We would get something that has a large userbase, reasonable
 performance, is reliable and has all the strange problems we're having
 (like short reads, filling buffers) already solved.
  * It allows people to write their modules in whatever language they like,
 there are binding to nearly everything (haskell, java, perl, Qt, …).
  * We might integrate better into the rest of the system. We could use the
 system bus by default and provide signals about important events, we might
 listen for events from NetworkManager (not that I would believe many
 servers do have the beast).

 Discussion welcome.

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