[bind10-dev] Our messagebuss again

[Michal 'vorner' Vaner]

Hello

I was thinking in a bus (yes, even such things happen simetimes…) and I was
thinking abound dbus and our message bus. When I originally suggested using
dbus, I thought we would just take whatever libraries are there and use. Easy
task. It turned out not to be the case (no libraries for C++, libraries for
python 3 appeared just like sometime now, bad licence). So we would have to wrap
around the C low-level dbus library to C++ and then wrap it again to python.

So maybe it is still easier to fix the problems we have with our message buss.
What I think is the protocol is mostly OK, only the implementation lacks few
things. To list them:
 • We can't send file descriptors. Therefore we do a nasty hack around the
   socket allocator and boss. That is not a high priority, because we already
   have the workaround, but it would be very nice to fix it sometime. The fix I
   propose is to include another number to the header of a message ‒ number of
   file descriptors attached to the end of the message ‒ and a new type, which
   could reference them.

 • We have hard time wrapping some C++ libraries which use the communication,
   because we have incompatible python library to talk to message queue. The
   proposed solution would be to drop the python implementation and wrap the c++
   one.

 • Easy to use RPC. We have a way to send a command and wait for the answer
   (either synchronously or asynchronously). But it is cubersome. I think we
   should introduce some methods like result = cc.callSync("Auth", "ping",
   parameters); and cc.callAsync("XfrIn", "retransfer", parameters, callback);

 • No way to reasonably „broadcast“ an event or information. The bind10 should
   be modular. That means, we can not know now whatever component might be
   interested in knowing that a new zone is being added, it was updated or
   another entity connected or disconnected from the buss. Currently we send a
   message (command) to a given type of component (like to Auth) and if anything
   else wants to see the „notification“, it needs to pretend it is Auth to get
   them. What I think we should do is create a signalling mechanism ‒ each type
   of component has some „signals“ (listed in the spec file, for example) and
   anybody can register to get specific ones. The bus would keep the
   subscriptions and send them to the interested recipients when the signal
   happens. This would mean adding some more types of requests to the header
   part of message, but it should not be problem.

 • There are problems with addressing. We can address a type of component, but
   addressing a specific component instance is hard. They do have an address,
   but nobody knows the address. This could be solved by signal about connection
   or disconnection of a component.

 • Logging and configuration of the message queue itself. This could be solved
   by making the message queue also connect to itself and communicate as the
   rest. It could register the signal when cfgmgr connects and then request its
   own configuration (after providing it with its own spec file). It could also
   be possible to Shutdown it correctly by a command.

 • Ability to see all the messages going through a bus or specific components.
   There could be a specific logger for it in msgq, logging at something like
   DEBUG/100.

 • There's bunch of strange bugs in the libraries. Dropping one of the copies
   would likely decrease the number of bugs, but we still need to go through the
   C++ one and solve all the possible things like synchronous call within the
   command loop (I believe there's a workaround for it somewhere).

Any ideas about it? I believe this should solve most of our problems and be less
work than implementing the dbus wrappers.

With regards

-- 
Anyone who goes to a psychiatrist ought to have his head examined.
		-- Samuel Goldwyn

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120319/4e71b3ac/attachment.bin>