[bind10-dev] proposal: revising listen port configuration

[JINMEI Tatuya / 神明達哉]

At Wed, 4 Apr 2012 09:19:05 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> On Tue, Apr 03, 2012 at 11:15:09AM -0700, JINMEI Tatuya wrote:
> > ...we should consider the case where the acquisition of new socket
> > fails after the server responds to the config update.
> 
> Do we really? I mean, it kind of makes sense to be able to respond to a command
> asynchronously as well. So the workflow would look like:
>  • We got a config update.
>  • So we send out bunch of requests for the new sockets, with a callback.
>  • We return, but don't send the answer yet.
>  • Sometime later, the callback(s) is(are) called. We change the sockets and
>    send the answer.
> 
> But I'm not sure if it's really worth it.

It may not be impossible, but is not easily adaptable to the current
design because all communications between bindctl and cmdctl, cmdctl
and cfgmgr, and cfgmgr and auth/resolver are currently all
synchronous.

> Anyway, I'd very like to be able to decouple the config validation from config
> update operations, for several reasons. Now, with multiple instances of
> components, each of them validates. If they don't agree on the validity, race
> conditions happen and the fastest to answer wins. Handling of local and remote
> config is different. And we have no way to validate config if the component is
> not running.
> 
> If the validation was taken out of the process and placed somewhere else, the
> config update would be just a notification and there would be no answer to it
> anyway.

I guess some part of my initial suggestion is aligned with this,
although probably for different purposes.  In that suggestion I
propose separating operation-level validation for listen_on (i.e.,
whether the socket is really acquired) from the checks requested by
cfgmgr.  So, basically listen_on request would always succeed in the
view of cfgmgr, and in that view cfgmgr and auth/resolver are always
consistent, but the requested socket may not always be open.  And,
this way, it's not a problem if "the acquisition of new socket fails
after the server responds to the config update."

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.