BIND 10 #2101: [meta] memory-efficient version of InMemory Zone

[BIND 10 Development]

#2101: [meta] memory-efficient version of InMemory Zone
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  meta
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> This feature consists of some other subfeatures:
>
> - Updates to libdns++ `LabelSequence`: #2086, #2087
> - Introduce `MemorySegment`: #2088
> - `RBTree` updates so it will be more memory efficient, using offset
>   pointer and provide other support methods: #2089, #2090, #2091,
>   #2092, #2093
> - Memory efficient `Rdata` encoding: #2094, #2095, #2096
> - Introduce `RdataSet` and define new `RRset`: #2097, #2098
> - `InMemoryZone` client/finder update: #2107, #2108, #2109, #2110, #2218
> - Update `ZoneTable`: #2100
>
> General notes: when we complete this, we'll have a slightly different
> version of the proposed design
> http://bind10.isc.org/wiki/InMemoryZoneDesign
> - It will encode names in RDATA as raw data for `LabelSequence`, not a
>   pointer to the corresponding tree node
> - As a result, it doesn't support additional section shortcut
>
> I thought the above tasks are already pretty big, so it's probably
> better to complete a suboptimal but workable version first.
>
> It's unlikely that we'll revise the existing in-memory data source
> implementation incrementally without making it unworkable for the
> moment.  So, realistically, we should implement these while keeping
> the current version intact (using a slightly different name or
> separate subdirectory, etc), and when everything is done, replace the
> existing one with the new one (that itself will probably have to be a
> separate task).
>
> Also, we may want to rename `RBTree` more generic using this
> opportunity, such as `DomainTree` so that if and when we want to
> change the internal tree algorithm from RB tree the class name won't
> be affected.

New description:

 This feature consists of some other subfeatures:

 - Updates to libdns++ `LabelSequence`: #2086, #2087
 - Introduce `MemorySegment`: #2088
 - `RBTree` updates so it will be more memory efficient, using offset
   pointer and provide other support methods: #2089, #2090, #2091,
   #2092, #2093
 - Memory efficient `Rdata` encoding: #2094, #2095, #2096
 - Introduce `RdataSet` and define new `RRset`: #2097, #2098
 - `InMemoryZone` client/finder update: #2107, #2108, #2109, #2110, #2218
 - Update `ZoneTable`: #2100
 - Integration: #2219 (when all others are done)

 General notes: when we complete this, we'll have a slightly different
 version of the proposed design
 http://bind10.isc.org/wiki/InMemoryZoneDesign
 - It will encode names in RDATA as raw data for `LabelSequence`, not a
   pointer to the corresponding tree node
 - As a result, it doesn't support additional section shortcut

 I thought the above tasks are already pretty big, so it's probably
 better to complete a suboptimal but workable version first.

 It's unlikely that we'll revise the existing in-memory data source
 implementation incrementally without making it unworkable for the
 moment.  So, realistically, we should implement these while keeping
 the current version intact (using a slightly different name or
 separate subdirectory, etc), and when everything is done, replace the
 existing one with the new one (that itself will probably have to be a
 separate task - which is #2219).

 Also, we may want to rename `RBTree` more generic using this
 opportunity, such as `DomainTree` so that if and when we want to
 change the internal tree algorithm from RB tree the class name won't
 be affected.

--

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