[bind10-dev] Thinking aloud: Receptionist

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/20/2010 12:20 PM, Stephen Morris wrote:
>>
>> We didn't yet decide, if we want the receptionist or not (for those who don't
>> remember, a process for deciding, where a request would go). There are people
>> who think we will need recursive+auth binary, but some (like me) still find
>> receptionist nicely flexible.
>>
>> There are many things the receptionist could be used for:
>> • Deciding between recursive/auth, of course.
>> • Getting rid of the problematic link between auth←→xfrout.
>> • Shielding the components of badly formated headers, long-living idle TCP
>>  connections, etc.
> 
> The only problem with putting functionality into the receptionist is that you end up having to run a receptionist even if you are just running a single component.  This adds overhead - even if it is small.
> 

just like msgq, boss, and socketcreator ;)

but i would say, IF we have a receptionist, I'm actually not against letting it
do a fair amount of work (provided that other modules won't have to do it again)

>> • Adding new/custom components with just providing some filter rule or plugin
>>  (shared library), or, if there's no need for speed, by embedded python code.
> 
> Is the idea that the receptionist filters the packet via a user filter and then passes it to the component in question?  If via a plugin, why not add the capability to accept plugins to the resolver and authoritative server?
> 

assuming for a minute here that we would go for a receptionist model; I'd say
there is room for both actually.

A receptionist could have a set of rules like 'incoming event on iface 1 port x
goes to module A. For incoming events on iface 2 port y we have this custom
ruleset which determines it goes to either module B or C'

(note that i am abstracting away from DNS specifics here)

The big decider is how to efficiently convey whatever it has read to a module;
if we can do that (and that is a big if) we can remove network-specific for
receiving stuff from all modules, and let the receptionist be the only one that
is actively listening to the outside world. An addendum to that is that it
probably won't be able to decide on its own in all cases, so those rules might
need to contain something like 'give it to module A, if it is not able to handle
the event, give it to module B'.

The internal hooks thing would have use if people don't want to provide a full
module, but just a set of calls that can modify an event and/or an answer at
certain points in the logic. This would have the advantage of not needing a full
module, and not needing to know all details going on in our modules (like
learning c++/coroutines etc ;)). It would also mean less extensive rule-writing,
since the deciding-whether-to-do-anything can be done by the logic in the calls
themselves.

> 
>> • Some pre-parsing could be done there and taken to a common place.
> 
> See above for the drawback of putting functionality in the receptionist.
> 

i'd say it should do full parsing (and scrubbing), given my two requirements
above; that modules do not have to do it again, and that the parsed data can
efficiently be passed along. The first of those mostly depends on the second
one. Perhaps this is only possible if we come up with a msgq that is way, way
more efficient than what we have now (which is probably very useful without a
receptionist too), but of course i have no real proposal for that at this point :)

> 
> My feeling is that if you are running both a resolver and authoritative server on your system it is unlikely that you will be running a really large zone.  So the following are also feasible:
> 
> a) Pre-load the resolver's cache with non-expiring authoritative records (and provide some way to update it should the authoritative data change). Providing that answers to queries for these records always contain the AA bit set, the presence of the resolver would be invisible.
> 
> b) Run the authoritative server on the same machine and configure the resolver to direct queries for the authoritative zones there (e.g. run it on a separate port or provide an inter-process communication mechanism). Essentially the resolver is acting as the receptionist.
> 

- From the setups and feature requests for dns products i've seen, really
high-performance authoritatives usually run on their own. Most resolves need a
minimal set of auth data. But one of the requests we're going to get a lot is to
extend that set :) So an option to run a real auth should be there.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0TbZgACgkQ4nZCKsdOncXG7QCfa3gShI7r0Rfn/RPmPpbkCTw1
N20AoIVPCOgYaT+kq5iKwODgTuV7kQMB
=cKd9
-----END PGP SIGNATURE-----