BIND 10 #1775: update in-memory getAdditional() to handle wildcard match for additional names

[BIND 10 Development]

#1775: update in-memory getAdditional() to handle wildcard match for additional
names
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  high   |  Sprint-20120403
                  Component:         |            Resolution:
  Unclassified                       |             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 vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:8 jinmei]:
 > > Also, it is not obvious why the size of the tree that is created to
 hold the wildcard-constructed additionals can't grow and grow (I thing I
 found a reason after some time of thinking, though). Would it be possible
 to comment on why the size is bounded by the characteristics of the zone?
 >
 > I'm not sure if I understand the concern, but I tried to add some more
 > explanations at d3e876a.  Does that address it?

 More or less. I was worried that someone could create queries where each
 one would add a new name to the tree, which would make it eat all memory.
 However, this can't happen since the name must be as the RData in some
 other thing in the zone. This is easier to follow from this description
 than before.

 > As explicitly commented, however, I re-read the code, and found one
 > way that may not be so ugly or sacrifice the performance (40d727b).
 > Would it be better?

 I believe so.

 > In any case, I'd note that one fundamental background issue is that
 > RBTree::find() (which findNode() internally uses) breaks constness:
 > even if it's a const member function, it actually returns a mutable
 > pointer via 'node' which points to its internal data.  Ideally, we
 > should provide const and non const versions of RBTree::find().  Then
 > the issue around findNode() could be solved much more cleanly.  But
 > that would also be non trivial (if we also want to avoid logic
 > duplicate), and would be a separate issue anyway.

 Well, it breaks constnest on the logical level, but not on the compiler
 definition level. The compiler now has all information on what can or can
 not change.

 > If the latest branch addresses the comments, I think I've addressed
 > all points so far.  But I plan to add some more things after that, so
 > regardless of whether they are okay, I'll still continue to work on
 > this ticket (but it'd be nice if you could confirm the updates so far).

 I think they are OK.

 Thanks

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