[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