Re: async resolver

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Wed, 21 Oct 2009 16:26:25 +1100

On Wednesday 21 October 2009 09:03:33 Murray S. Kucherawy wrote:
> > -----Original Message-----
> > From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> > bounce_at_lists.opendkim.org] On Behalf Of Murray S. Kucherawy
> > Sent: Tuesday, October 20, 2009 9:55 AM
> > To: Daniel Black; opendkim-dev_at_lists.opendkim.org
> > Subject: RE: async resolver
> >
> > It's hard to tell whether or not that scenario is really something
> > about which we should be concerned, though, without more data. The
> > only other concern I have is the amount of code that would have to
> > change. Not a bad thing, just thinking out loud for planning purposes.
>
> More of that out-loud thinking:
>
> If there's no callback facility in the underlying resolver selected by the
> administrator, we can't do any of this.
correct - my main motivation for c-ares preferably or libar enhancements.

> That would mean libopendkim has
> two basic DNS structures, one that can initiate queries and come back to
> them later and one that has to block at the same time the query is sent
> because the callback facility isn't available. That's a lot of cpp fun,
> more than is already there, which makes the code a pain to manage.

time for a cull of options? or an abstraction?

> Just using the ADSP part: With a callback facility, the ADSP query could be
> started in dkim_eoh_verify()
or dkim_header() ?
> and then evaluated (which could block) all
> the way down in dkim_eom_verify(); but without, we would do it in one
> place or the other and block every time.
yes

> For the DKIM part, we could launch the queries in dkim_eoh_verify(),
or dkim_header()
> one
> for each signature seen. If we want to do the body optimization, we have
> to complete the DNS query and do the verification prior to returning from
> that function; if we want to risk unnecessary body I/O then
> dkim_eoh_verify() can return and then in dkim_body() we would check for
> responses to each of the key queries and run the verifications of them
> once they've arrived.

so format and hash incrementally or increase buffer until we have a key and
then catchup?

> Then, if all of those verifications fail, we can
> tell the filter to stop sending us message body because we know it won't
> be useful.
yes
> In this case we've wasted some hash cycles
or memory
> and I/O, but it's possible the optimization is an overall gain for an
average mail stream.
i'm hoping, or at least for the high end mail streams.

> However, without the callbacks, the key retrieval will have to block
> entirely either in dkim_eoh_verify() or in dkim_eom_verify().

yes

same async principles apply to query cache too though given berkdb's apis
maybe not.
Received on Wed Oct 21 2009 - 05:26:51 PST