BIND 10 #2097: Define and Implement RdataSet class

[BIND 10 Development]

#2097: Define and Implement RdataSet class
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120731
  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:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> As proposed in
> http://bind10.isc.org/wiki/InMemoryZoneDesign#a4.2.RdataSetstructure.
>
> With the help of separate encoder, this class will be actually pretty
> simple.
>
> {{{#!cpp
> struct RdataSet {
>     // Constructor.
>     RdataSet(dns::RRType type, dns::RRTTL ttl, uint16_t n_rdata,
>              uint16_t n_rrsig);
>
>     // allocator and deallocator so we can create it from a memory
> segment.
>     // allocate() will use RdataEncoder, adding RDATA of rrset and
> sig_rrset,
>     // allocate memory, and pass the region to its encode().
>     static RdataSet* create(MemorySegment& segment,
>                             RdataEncoder& encoder,
>                             dns::ConstRRsetPtr rrset,
>                             dns::ConstRRsetPtr sig_rrset);
>     static void destroy(MemorySegment& segment, RdataSetPtr rdataset);
> }}}
>
> Depend on #2094 and #2095.
>
> The type of "(RR) type" member may better be of dns::RRType, instead
> of uint16_t.  At the risk of assuming its internal representation is
> essentially a 16-bit integer, it will help avoid overhead of
> constructing the type object in performance sensitive operation.
>
> Updated suggestion about encoding num_rrs: on further thought, we
> wouldn't even have 16384 RRs in practice, because each RR has
> at least 10-byte of fixed data (type, class, TTL, RDATA), so for an
> `RRset` to fit in a DNS message reasonably, the max possible number
> of RRs is 8191 (`2^13 - 1`).  Also, even if a normal RRset could have a
> pretty large number of RRs (e.g., hundreds), it would almost always be
> the case that there are only few RRSIGs of them.  I guess something up
> to 6 is normally more than enough in practice, and so the revised
> bitfields are:
>
> {{{#!cpp
>     uint16_t num_rrsigs : 3; // # of RRSIGs, up to 6 (7 means more than
> that)
>     uint16_t num_rrs : 13;   // # of RRs, up to 8191
> }}}
>
> In `create()`, if the number of RDATAs exceeds 8191 we just reject the
> RRset by throwing an exception.
>
> If the RRset isn't signed num_rrsigs is simply 0.  If it contains 7 or
> more RRSIGs, num_rrsigs will be set to 7 (all 1), and we'll add a
> 2-byte optional field immediately after the main struct.
>
> This way, we should be able to keep the data size minimal in the
> majority of cases, and we can encode the number of normal RRs and
> RRSIGs outside of the encoded data (in fact #2095 currently assumes
> number of RRSIGs is maintained outside of the encoded data).

New description:

 As proposed in
 http://bind10.isc.org/wiki/InMemoryZoneDesign#a4.2.RdataSetstructure.

 With the help of separate encoder, this class will be actually pretty
 simple.

 {{{#!cpp
 struct RdataSet {
     // Constructor.
     RdataSet(dns::RRType type, dns::RRTTL ttl, uint16_t n_rdata,
              uint16_t n_rrsig);

     // allocator and deallocator so we can create it from a memory
 segment.
     // allocate() will use RdataEncoder, adding RDATA of rrset and
 sig_rrset,
     // allocate memory, and pass the region to its encode().
     static RdataSet* create(MemorySegment& segment,
                             RdataEncoder& encoder,
                             dns::ConstRRsetPtr rrset,
                             dns::ConstRRsetPtr sig_rrset);
     static void destroy(MemorySegment& segment, RdataSetPtr rdataset);
 }}}

 Depend on #2094 and #2095.

 The type of "(RR) type" member may better be of dns::RRType, instead
 of uint16_t.  At the risk of assuming its internal representation is
 essentially a 16-bit integer, it will help avoid overhead of
 constructing the type object in performance sensitive operation.

 Updated suggestion about encoding num_rrs: on further thought, we
 wouldn't even have 16384 RRs in practice, because each RR has
 at least 10-byte of fixed data (type, class, TTL, RDATA), so for an
 `RRset` to fit in a DNS message reasonably, the max possible number
 of RRs is 8191 (`2^13 - 1`).  Also, even if a normal RRset could have a
 pretty large number of RRs (e.g., hundreds), it would almost always be
 the case that there are only few RRSIGs of them.  I guess something up
 to 6 is normally more than enough in practice, and so the revised
 bitfields are:

 {{{#!cpp
     uint16_t num_rrsigs : 3; // # of RRSIGs, up to 6 (7 means more than
 that)
     uint16_t num_rrs : 13;   // # of RRs, up to 8191
 }}}

 In `create()`, if the number of RDATAs exceeds 8191 we just reject the
 RRset by throwing an exception.

 If the RRset isn't signed num_rrsigs is simply 0.  If it contains 7 or
 more RRSIGs, num_rrsigs will be set to 7 (all 1), and we'll add a
 2-byte optional field immediately after the main struct.

 This way, we should be able to keep the data size minimal in the
 majority of cases, and we can encode the number of normal RRs and
 RRSIGs outside of the encoded data (in fact #2095 currently assumes
 number of RRSIGs is maintained outside of the encoded data).

 Note: there's a small dependency on #2096: we'll need
 `RdataReader::getDataLength()` (or some equivalent to it) to implement
 destroy().  But we can probably work on these two in parallel (if
 necessary) by using a quick-hack version of the "equivalent to
 getDataLength" for this ticket.

--

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