BIND 10 #1608: implement ZoneFinder::Context::getAdditional() for in memory data source (was: implement findAdditional() for in memory data source)

[BIND 10 Development]

#1608: implement ZoneFinder::Context::getAdditional() for in memory data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:  major  |  Proposed
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  auth   |           Total Hours:  0
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jinmei):

 * milestone:  Year 3 Task Backlog => Next-Sprint-Proposed


Old description:

> This is a subtask for "Pre-establish shortcuts for additional section
> processing" described in
> https://lists.isc.org/pipermail/bind10-dev/2012-January/002985.html
>
> It depends on #1605 and #1607.
>
> In this task we extend the (tentatively named) `RBNodeRRset` so that
> it stores a shortcut to the RBNode corresponding to its each RDATA.
> For example, an NS `RBNodeRRset` maintains a list of pointers to the
> RBNodes corresponding to the NS names of its RDATAs.  In our current
> implementation this only happens for NS and MX (in future we should
> extend and generalize it).
>
> In my experimental implementation, I built a tentative list of all NS
> and MX RRsets while loading the zone content, and once the zone is
> built, build the additional pointer list for each NS and MX RRset
> stored in the tentative list.  Then release the list.  This
> tentatively requires more memory, so if there's a simpler way to build
> it more incremental, that would be nice.
>
> On top of this setup, the in memory version of findAdditional() checks
> the pointers to the RBNodes, and search for requested types of RRsets
> at each node.  Then push all found RRsets to the result vector and
> return.
>
> This task completes the entire shortcut feature.

New description:

 This is a subtask for "Pre-establish shortcuts for additional section
 processing" described in
 https://lists.isc.org/pipermail/bind10-dev/2012-January/002985.html

 It depends on #1605 and #1607.

 In this task we extend the (tentatively named) `RBNodeRRset` so that
 it stores a shortcut to the RBNode corresponding to its each RDATA.
 For example, an NS `RBNodeRRset` maintains a list of pointers to the
 RBNodes corresponding to the NS names of its RDATAs.  In our current
 implementation this only happens for NS and MX (in future we should
 extend and generalize it).

 In my experimental implementation, I built a tentative list of all NS
 and MX RRsets while loading the zone content, and once the zone is
 built, build the additional pointer list for each NS and MX RRset
 stored in the tentative list.  Then release the list.  This
 tentatively requires more memory, so if there's a simpler way to build
 it more incremental, that would be nice.

 On top of this setup, the in memory version of
 ZoeFinder::Context::getAdditional() checks
 the pointers to the RBNodes, and search for requested types of RRsets
 at each node.  Then push all found RRsets to the result vector and
 return.

 This task completes the entire shortcut feature.

--

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