[bind10-dev] proposal: revising listen port configuration
JINMEI Tatuya / 神明達哉
jinmei at isc.org
Tue Apr 3 18:15:09 UTC 2012
At Mon, 2 Apr 2012 10:00:48 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> > - when the listen_on configuration is updated, the current
> > implementation first releases all open sockets, and then tries to
> > open (acquire) sockets for the specified port. This is wrong for
> > several reasons: first, it can cause temporary service disruption
> > (which would actually be real for busy servers). Further, this can
> > be permanent service disruption if the operation results in
> > re-acquiring a socket for a port already in use but the attempt of
> > the second acquisition fails.
>
> This can be done in a much easier way now, thanks to the socket creator. I had a
> feeling I already did the change, but I see the old code in master now, so maybe
> I just imagined how it would look like. Anyway:
Yes, this seems to work.
Whichever way we do this, however, if we want to make it asynchronous...
> I agree we want to have some kind of asynchronous communication, but I think
> this needs to be addressed in more general way than just the socket creator. I'd
> like the msgq to be able to send file descriptors too, which would mean we would
> just need to call several RPCs asynchronously and wait for all the results to
> come back, avoiding the juggling with unix-domain sockets for transferring them.
...we should consider the case where the acquisition of new socket
fails after the server responds to the config update.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
More information about the bind10-dev
mailing list