BIND 10 #2778: Shared memory data source design

[BIND 10 Development]

#2778: Shared memory data source design
-------------------------------------+-------------------------------------
            Reporter:  shane         |                        Owner:
                Type:  task          |  jinmei
            Priority:  high          |                       Status:
           Component:  data source   |  accepted
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130305
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  8             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  shared-memory datasource
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Old description:

> The current in-memory data source requires a separate copy for each
> process. We want to replace this with a shared-memory data source, either
> based on System V shared memory or mmap. This ticket is to design this.

New description:

 The current in-memory data source requires a separate copy for each
 process. We want to replace this with a shared-memory data source, either
 based on System V shared memory or mmap. This ticket is to design this.

 Content of #2331:

 -----

 We eventually need to support this; otherwise multiple instances of
 b10-auth require multiple copies of in-memory image for the same data.
 Obviously it doesn't scale with huge size of zones and many instances
 of b10-auth running on many-core boxes.

 Actually we shouldn't be very far from this goal. The internal data
 structures should be fully offset-pointer based, and all memory
 allocation/deallocation are encapsulated with an abstraction of
 MemorySegment, which should be easily adapted to Boost
 managed_shared_memory or managed_mapped_file.

 We still have to think about several non trivial things:

   * overall design of a memory management process (assuming there will be
 a new module, tentatively named "b10-memmgr"). how to create and update
 memory image in a shared memory region or on a mapped file.
   * inter-module protocol between memmgr and others (auth, xfrin, DDNS,
 etc)
   * maybe configuration

 The goal of this ticket is to have discussions on these topics, maybe
 led by someone with initial proposals, and (possibly) create specific
 development tickets.

--

Comment (by shane):

 This appears to be a duplicate of #2331... sorry! However, since this one
 is accepted I'll close the other.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2778#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development