[bind10-dev] DNS message API: the message class

[David W. Hankins]

On Thu, Oct 08, 2009 at 12:46:24AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> Of course, in theory this approach has a scalability issue because we
> can have up to 65536 RR types, some of which may contain multiple
> fields.  In practice, however, the number of standard types is much
> smaller than the maximum, and will still be relatively small
> throughout the lifetime of BIND10 (am I optimistic?).

As a similar sidenote; in DHCP we have a slightly different set of
constraints that means that per-option handwritten functions does not
really scale (even just at 256 IPv4 DHCP option codes).  The current
byte-compiled format code in DHCP maybe is not the implementation I
would have chosen, but something similar is necessary.

Not to mention that we have vendor defineable options, which I do not
think is a consideration in DNS.

But I think that if we have to have that sort of abstraction layer
anyway, where handling the conversions between config, memory, and
wire formats for pieces of served DHCP data is done procedurally
rather than by hand-tailored functions, that the DNS side of the house
could also benefit, and we'd have another common point in shared
libraries.

So it may at least be worth investigating...

I think this starts to look like "data types", where the rdata
function, knowing its RR code as well and so having a key to discover
the typed-data-format of the RR, would assert an error if a request
for some data type (or array indexed data type) were not a valid
request considering the format, as well as being able to request or
set the wire, memory or database (if different), and printable
formats.

Supposing for example the current class-based extra routes option in
DHCPv4 (note: I'm guessing at the order);

  for (int i = 0 ; i < rdata.getArrayCount() ; i++) {
    CIDR dest;

    dest = ClassToCIDR(rdata.get_v4Address(0, i));
    addRoute(dest, rdata.get_v4Address(1, i));
  }

Where 'get_Address(x, y)' is 'x= field index in this array index',
and 'y= array index'.  I think this could be improved by providing
defineable names for fields, but I'm not sure how to do that scalably.
Providing an ASCII string seems suboptimal; all those strcmp's.  And
enumerations limit us to those options known at compile time (rather
than config time).

It is possible we could use a hybrid approach of all three;
enumerations for standard (non-vendor) field indexes known at compile
time, by direct index as exampled above if the enumeration isn't
known, and then a function to derive the field indexes from their
labeled names rather than from integer indexes for software that is
not so performance encumbered (a good programmer could remember this
in a variable rather than asking for strcmp's on every object being
processed).

  index = rdata.format().getIndexOf("gateway");

I would probably also call this a 'data' object instead of 'rdata'. :)


In this case we would expect it would throw an exception if a request
was made for a field that doesn't exist or is mistyped either in the
by-array-slice format (by index or name in the two examples), or out
of array bounds.  The 'get_v4Address' function knows it needs a 32-bit
field.  If there isn't one at the index provided, you just error out.
If there is one, but it isn't an "IPv4 address" according to the
format, you helpfully provide the conversion.  If the field is a DNS
name, maybe providing the recursive A lookup is being /too/ helpful.

So maybe it can be improved;

  for (int i = 0 ; i < rdata.getArrayCount() ; i++)
    AddRoute(rdata.get_CIDR(0, i), rdata.get_v4Address(1, i));


Also one thing to consider is that for performance-encumbered code
we will want to be able to return a pointer to the rdata contents to
the caller, rather than copying the data into a new object, so as
to avoid excessive memcpy's.

That is, for larger data objects.

DHCP currently does an arcane thing with "data_string"s passed by
the caller into the data store, and "buffer"s allocated by the data
store and referenced in the caller's data_string, which is really
overkill for any field smaller than 3x the pointer size, but it
uses it for everything anyway.

But we do get the odd long option, so it beats copying the packet
around every time someone wants to know a bit of data...


And please note I'm on cold medication.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20091008/b89dd1bc/attachment.bin>