[getdns-api] async comments (0.268)

[Phillip Hallam-Baker]

On Mon, Feb 4, 2013 at 12:21 PM, Dan Winship <dan.winship at gmail.com> wrote:

> On 02/04/2013 11:07 AM, Phillip Hallam-Baker wrote:
> >     > The callback function might be called at any time, even before
> >     > getdns() has returned.
>
> > I am not sure this is avoidable. The API call cannot control the
> > scheduler. If there are 50 threads going at once there can be no
> > guarantee that the parent thread will get called before the callback
> > thread is called.
>
> Hm... OK, we have different models of how this works... your
> interpretation makes sense if getdns() behaves like BeginInvoke with an
> AsyncCallback. But in that case there's not really an event loop
> involved... if getdns() wants to just do blocking I/O in another thread
> and then call the callback from that thread when it's done, it doesn't
> need to know anything about how the rest of your program handles
> events/asynchronicity.
>
> I was assuming that you'd call getdns() in the thread where the event
> loop was running, the event loop would then dispatch events to getdns
> (in this same thread), and then eventually one of those events would
> result in getdns invoking your callback (in the same thread). Section 8
> says "contexts in implementations of the API will not necessarily be
> thread-safe", so it seems like it would be illegal for an app to call
> getdns() from any thread other than the one where the event loop was
> running, and likewise it would be illegal for the event loop to call
> back to getdns from any thread other than the one that getdns registered
> itself in.
>
> (When the docs talked about the callback running before getdns()
> returned, I assumed it was suggesting that getdns() might invoke the
> callback directly, eg, if it already had the answer cached and didn't
> need to do any I/O.)
>
> But anyway... the docs for getdns_cancel_callback() seem to agree with
> your interpretation ("getdns_cancel_callback() may return immediately,
> even before the callback finishes its work and returns." That definitely
> implies the callback might be running in another thread.) So I guess I'm
> confused about what's intended here.
>

Being confused could be the product of the spec not being clear or the idea
behind the spec not being clear. Neither is good.

The UNIX approach I am familiar with is the pre-threads approach.

Another little curveball that I encountered today is the consequence of the
fact that each UDP request has to be made on a different client socket so
as to avoid spoofing attacks. That actually simplifies the C# code but I
can see it making a mess of various sockets approaches.


Looking at it from the client side, I see two cases of interest:

1) We are implementing a non forking, single thread per CPU client tuned
for maximum speed.

2) We are implementing a client that uses threads.


Case (1) is really going to depend on what style of calling loop we are
dealing with. The simplest approach might well be to allow the programmer
to make the UDP calls themselves and provide convenience functions to
handle the messages returned.

If we are in case (2) then we don't really care (much) about blocking I/O
because that is what threads are for. Or rather we wouldn't if we could
query for multiple DNS RR types in one go. If we want to pull the A and
AAAA records, we really want to issue both queries in parallel and it is
rather a lot of effort to have to spin up a separate thread just to
accomplish that.

Queries for SRV records and A record in parallel are a little more complex
as the domain argument is different for both.

So the sort of convenience call I was working on today was something like
the following:

typedef struct _DNSQuery {
    char * domain;
    ushort query
    } DNSQuery;

GetDNS (DNSClient *client, DNSQuery QueryArray, int count Query)


This is a lot better from a 'be kind to DNS' perspective since it prevents
the programmer fro firing off a hundred queries in parallel. While this is
in theory permitted by the DNS protocol, the network consequences of doing
that are 'doubleplusungood'. I am told that many home routers and firewalls
will tend to drop more than four queries at once.





-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vpnc.org/pipermail/getdns-api/attachments/20130204/d98e6cb1/attachment.html>