[bind10-dev] hooks in recursive server processing (plus a general comment)

[Jerry Scharf]

First, I want to thank everyone on the development team. I have brought 
in some pretty unusual ideas and requests, and the team has always been 
willing to engage whether they make sense and how to make these work. 
This doesn't happen all the time and I wanted to say how much easier 
(and more fun) it makes my work.


This is what happens when a marketing person carelessly steps into the 
how rather than the what. :)

Mickal's idea makes sense to me for a different reason. I was concerned 
that at each possible point of interest there would be a subroutine call 
that did nothing in 99% of all installations. I was worried about the 
performace impact when we are trying to squeeze every qps possible out 
of the code. With the list idea, a single "if (list) ..." test (with a 
predictive miss) would have far less impact to the normal processing case.

One minor consequence (and a huge win for BIND 10's modular design) is 
that you will need to restart the processing module when a change is 
made to either the list of needed external routines or their code. Being 
able to start the new instance, let it get to full functioning state and 
then have it take over the query processing means that these changes are 
possible without the down time of a BIND 9 restart.

There will be some fun figuring out the best way to connect these 
external functions to the binary only server and how to make it manageable.

warmly,
jerry

On 01/21/2011 06:04 AM, Michal 'vorner' Vaner wrote:
> Hello
>
> On Fri, Jan 21, 2011 at 11:24:24AM +0000, Stephen Morris wrote:
>> For performance reasons, I don't think these could be done by external modules.  The way I was thinking of would be to load a dynamic library at run-time.  So we supply a default library in the distribution directory, each function comprising nothing more than a return statement.  This is loaded at run-time unless a configuration option is set, in which case we load a user-supplied one.  (As Michal pointed out, we might want to enable this feature by a compile-time option to avoid the overhead of calling empty functions.)
> Well, this has two problems. One is you can have only one callback. Then you
> can't combine the hooks together. Another is, call to dynamic library is more
> expensive (though not by much), so having an empty function in different library
> seems odd.
>
> If I was to design a callback system, I would have a list/chain of functions to be
> called at given point of execution. Each function could modify the ongoing
> packet (or, whatever was there) and return status (pass to next function, abort,
> say it is handled). Then the "usual" behaviour would be just the only one in
> default list. If we want an extension, a library would be loaded and it would
> add its own functions to the front of whatever lists it would like, intercepting
> all places it is interested in. So it could effectively modify the packets,
> handle them itself in a different ways, abort the whole process, count
> statistics, completely replace the logic, etc. And the only think it would
> require from us is to split the logic in parts, decide interfaces and have a
> template for the chained call. It seems simpler (or, at last, equally simple)
> and more powerful.
>
> Of course, this is just unfinished, unpolished, idea.
>
> What do you think about it?
>
> Have a nice day
>
>
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110121/c5d337dd/attachment.html>