[bind10-dev] MSGQ-NG requirements

[Michal 'vorner' Vaner]

Hello

On Thu, Apr 05, 2012 at 10:34:08AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> - I was not sure if a central server is an assumption (or is it an
>   implementation issue?)

Well, I kind of assume it would be there, for two reasons:
 • We have it now. I'd like to simply improve the current situation somewhat
   incrementally, instead of implementing something completely new (as I hope it
   would be less work with reusing what we have, or it would at least cause less
   disruption on the way).
 • Each module might want to communicate with many others (and, in case we
   support notifications, it might not even know with which modules). Doing it
   without a central server might be possible if we really insist, but I believe
   it would be much more complicated.

Is there a reason not to have a central server?

> - Regarding high-load support, I wonder whether we have any expected
>   scale where this generic msgq is applicable, or whether it's
>   "infinite".  I also wonder performance requirement in terms of
>   transaction speed.

By transaction speed, you mean the round-time trip? I kind of assumed the msgq
would be mostly idle (while the other components would be doing the real work),
and the communication happening on the local message, so it would not be a
problem. I'd be more worried about the speed in which a remote component is able
to answer.

And by the scale, I believe if the server is able to handle 1 000 000 zones, the
MSGQ should not be the bottleneck to prevent it. Otherwise, I don't think it
needs to be infinite, I just don't have the exact numbers.

> - "Multi-component support" and "Use of the bus from python-C++
>   wrappers" were simply not easy to understand for me.  For a "short
>   look", I didn't spend much time to try to understand them, so it's
>   just an impression rather than specific points to improve.  It's
>   just me, or some clarification help.

OK, I'll try to improve them.

With the multi-components, the problem is addressing. We use the addresses like
„Xfrin“ or „Auth“. But if there are two b10-xfrin modules running, sending
something to the „Xfrin“ address means both get the message. This is not what we
want in case of the message is „Would you kindly contact this server and
transfer this zone in?“, because then we would have two transfers in at the same
time. The probable result would be one starts downloading the zone, the other
fails to lock the DB and reports error. The zone manager gets the error and
assumes the transfer failed (and does not wait for the answer of the first
instance). We also need a way to point a finger at one of the instances and say
„You and only you, shutdown“ when the administrator changes the number of
instances from two to 1. So it would be nice to have something like „Xfrin[0]“
(first Xfrin instance) and „Xfrin[?]“ (any single instance of Xfrin).

With the wrappers, let's say we have a handy utility (the logging library, for
example) which communicates over the message bus with something else (it needs
to read configuration). It is written in C++ and takes the open connection as
parameter.

When we create a wrapper in python, we have a problem, because the open
connection in python is a separate implementation. There's no C++ object we can
take and pass as the parameter. If I remember correctly, the current logging
wrapper contains a nasty hack, where we register a python config handler,
convert the received data structures back to string representation, feed it to
the C++ JSON parser and push it to the throat of the logger. Even if this was
the easiest way to implement it, I don't believe it to be elegant.

If we had only the C++ connection library and the python would have a wrapper
around this one, we would not have the problem, as the wrapper would contain
the C++ object we can use.

With regards

-- 
A nuclear war can ruin your whole day.

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/20120405/dd46f1c4/attachment-0001.bin>