[bind10-dev] take 2: design and inter-process protocol for shared memory

[JINMEI Tatuya / 神明達哉]

(The original response was unicasted again, but I believe it wasn't
intentional, so I'm cc'ing the list in this response.)

At Thu, 14 Mar 2013 09:20:03 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

>  • We don't really need the _latest_ state in the mapped file. If the data
>    source contains journal, we can just ask for the diff from the version in the
>    file and the newest when updating (which we should do anyway, there can be
>    more than one change between the manager has time to do full update) and the
>    old version is available in the file (at least by the SOA, but we could store
>    it somewhere separately).
> 
>    If the data source does not have journal, then we need to rebuild from
>    scratch every time anyway, and we don't care what was the previous version.
> 
>    But I don't mind having an explicit „rebuild“ command.

Is this about Section 5.7?  If we always build all zones on the mapped
file (or apply outstanding diffs) on startup, you're right, this is
not an issue.  But I wanted to minimize the startup time as much as
possible when it's actually possible.  If the file to map already
contains the latest versions of the zone, the initialization can be
just done by mmap().

>  • Is there really a problem with the reconfiguration? I mean, if we get a diff
>    of old and new configuration, we can just remove the now unused files from
>    both readers and manager (independently), create files for the new ones and
>    send updates as on startup and try an update on the rest, just in case. We
>    would have to keep the old one, yes.

In my current gut feeling, it wouldn't be fundamentally problematic,
but I suspect we'll need to do some non trivial extension to the usual
update scenario.  The concept of configuration generation ID is one
such thing (although I've not fully considered if we really need such
a thing).

>  • Can mapping of the file fail? What happens, then? Do we abort? Do we complain
>    to manager and keep the old version?

In theory, it can.  But at least for readers, I think we can
reasonably assume it's very unlikely to fail as the manager should
have successfully mapped it just before that, so it would be
reasonable to consider any failure fatal.  For the manger, I think
it's okay to begin with treating it as fatal, too, but I think we'll
later have to make it more robust, e.g., by trying to remove any
existing file and creating a new image from the scratch.

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