BIND 10 #1805: implement getClosestNSEC() within InMemoryZoneFinder

[BIND 10 Development]

#1805: implement getClosestNSEC() within InMemoryZoneFinder
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120515
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  in-    |
  memory NSEC                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> Revised description to speed up development: we'll first complete a
> quick hack version of it so we can start other tasks without waiting
> for #1803 and #1804:
>
> We introduce a new (tentatively named) internal helper function (or
> method) of the in-memory finder.  It maintains an internal table of
> names in the getClosestNSEC() method (either by hardcoding the data,
> or by allowing the test to build it, or by actually iterating over the
> entire zone for every call), and uses that table to identify the
> "previous name".  Search the tree for the name that has NSEC and
> return it.
>
> Once #1803 and #1804 are completed we'll complete getClosestNSEC()
> using the getPreviousNode() interface.  That part will be deferred to
> a separate task.
>
> The following are the original description, kept for the record.
>
> This is a new (tentatively named) internal helper function (or method)
> of the in-memory finder.  It repeatedly calls
> RBTreeNodeChain::getPreviousNode() (see #1803) for the node chain used
> in find(), until it finds a node returned by getPreviousNode() that
> has NSEC (note there are cases where the node returned by
> getPreviousNode() doesn't have NSEC in the case of glue RRs).  Then it
> returns the found NSEC RRset.
>
> It depends at least on #1803.  Eventually it will need #1804 but can
> be started as soon as #1803 is completed (or even before that, as soon
> as the interface of getPreviousNode() is fixed if we want maximum
> concurrency).

New description:

 Revised description to speed up development: we'll first complete a
 quick hack version of it so we can start other tasks without waiting
 for #1803 and #1804:

 We introduce a new (tentatively named) internal helper function (or
 method) of the in-memory finder.  It maintains an internal table of
 names in the getClosestNSEC() method (either by hardcoding the data,
 or by allowing the test to build it, or by actually iterating over the
 entire zone for every call), and uses that table to identify the
 "previous name".  Search the tree for the name that has NSEC and
 return it.

 Once #1803 and #1804 are completed we'll complete getClosestNSEC()
 using the getPreviousNode() interface.  That part will be deferred to
 a separate task (#1962).

 The following are the original description, kept for the record.

 This is a new (tentatively named) internal helper function (or method)
 of the in-memory finder.  It repeatedly calls
 RBTreeNodeChain::getPreviousNode() (see #1803) for the node chain used
 in find(), until it finds a node returned by getPreviousNode() that
 has NSEC (note there are cases where the node returned by
 getPreviousNode() doesn't have NSEC in the case of glue RRs).  Then it
 returns the found NSEC RRset.

 It depends at least on #1803.  Eventually it will need #1804 but can
 be started as soon as #1803 is completed (or even before that, as soon
 as the interface of getPreviousNode() is fixed if we want maximum
 concurrency).

--

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