[bind10-dev] MSQ-NG requirements

[Michal 'vorner' Vaner]

Good morning

On Tue, Apr 10, 2012 at 12:58:36PM +0000, Steven Meyer wrote:
> I am at a disadvantage here because it is not obvious what the messages are that are exchanged between the various modules.  I think I have a handle on the session interfaces for groups for C++ and Python, but I am confused about the point-to-point configuration. Perhaps you have some additional documentation you can share? 

The documentation would be a problem I believe. In these parts of code, the
documentation is kind of lacking. We have the description of the interfaces, but
you say you already know that.

Also, there are the .spec files (each module has one). That one describes which
commands the module exposes, with the parameters it takes. Every other module is
allowed to call them, but it's not documented anywhere which module calls which
command. Also, the spec files describe which configuration items the module
knows about.

But to list what I know about, the messages are sent under these circumstances:
 • Startup. Each module connects, sends its spec (the context of the .spec file
   belonging to it) to the config manager. Then the config manager sends
   whatever non-default values there are for the module. There can be few more
   start-up messages (requesting sockets to listen on, for example), but I don't
   think there's more than 10 messages for each of the modules.
 • From time to time (every 10 seconds I think), modules that collect
   statistics send them to the statistics daemon to keep them. This is one
   message per module and I think there are like 2 or 3 modules that gather the
   statistics now.
 • When a zone times out, the zone manager asks the xfr-in to refresh it.
 • When there's a user interaction. This depends on what the user does, users
   can send direct commands to components or change the configuration. When the
   configuration changes, there's one command from the user interface to the
   config manager, the config manager then sends a command to each module whose
   configuration changed. After they all OK the updates, it sends OK to the user.
 • On shutdown.

So, we don't really have too many messages going through the bus, but they could
get slightly bigger (for example the statistics message could be large if there
are many zones).

A command looks like (if I remember correctly, but there are functions to format
it correctly somewhere):
['name-of-the-command', {'param': 1, 'another-param': []}]

It expects an answer in the form:
[rcode, result]

Where rcode is 0 if everything is OK and something else if there was an error.

I hope this helps as some kind of overview. Unfortunately, better documentation
that this is only the source code.

With regards

-- 
Security warning: Do not expose this email to direct sunlight.
It may lead to undefined behaviour, including possible data or life loses.

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/20120410/fdcef2d0/attachment.bin>