[bind10-dev] proposal: revising listen port configuration

[Michal 'vorner' Vaner]

Hello

On Thu, Mar 29, 2012 at 10:45:45AM -0700, JINMEI Tatuya / 神明達哉 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:
 • First, request all sockets for the new configuration. This is OK even in case
   the new configuration contains the same socket as the old one, since we use
   the SHARE_SAME and we are the same application as up trivially. So we get
   effectively `dup`ed copies of the same sockets, but we don't need to identify
   them.
 • If anything of above fails, return what we got already and abort the change.
 • If it was successful, switch the internals from old descriptors to the new
   ones. This should not fail, as it is just creating data structures, but we
   should handle it in some way nevertheless.
 • After that, close and release all the previous sockets. This will not hurt
   the same ones we already have in the new list, as the boss reference-counts
   them.

I believe the code for this is easier to write and read than explicitly finding
diff of the list of sockets.

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.

With regard

-- 
I left the ssh key under the doormat

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120402/ca13b37a/attachment.bin>