[bind10-dev] DNS message API: how to handle to-be-truncated case

[JINMEI Tatuya / 神明達哉]

At Wed, 30 Sep 2009 09:54:36 +0200,
Shane Kerr <shane at isc.org> wrote:

> I like the idea, but I'd prefer to do it without setting state. By this
> I mean the normal case is the same:
> 
>   message.to_wire();
>   message.sendto(somewhere);
> 
> But the truncated case is done using an optional parameter:
> 
>   message.to_wire(TOWIRE_ALLOW_TC);
>   message.sendto(somewhere);

Good point.  In my design I generally intended to separate the
"message" as an abstract notion of a DNS message and rendering related
information/algorithms.  In this sense, it should make more sense to
specify the truncation policy in somewhere else than the message
itself.

> We can allow other "to_wire()" options there too:
> 
>   message.to_wire(TOWIRE_ALLOW_TC | TOWIRE_DISABLE_LABEL_COMPRESSION);
>   message.sendto(somewhere);

This is certainly one option, but in general I'd avoid using the style
of an 'option' argument for optional behavior because it requires the
API user (=programmer) to be aware of the options even if they can
normally ignore the options (so they often need to specify something
like '0' in many cases).  So, your next suggestion seems to me more
appealing:

> If these become too complicated, then I'd rather see the to_wire()
> function have a "encoding options" object passed in rather than clutter
> up the message class with maintaining state.
> 
>   wire_fmt = new DNSMessageWireFormat();
>   wire_fmt.allow_truncation();
>   wire_fmt.disable_label_compression();
>   message.to_wire(wire_fmt);
>   message.sendto(somewhere);
> 
> Does this make sense?

in fact, I introduced a "renderer" class in my initial prototype,
which is expected to be used with a "message" and is responsible for
message rendering.  Right now, it simply encapsulates a packet buffer,
but we should probably move more states/functionality to that class.

---
JINMEI, Tatuya