[bind10-dev] Resolver skeleton, location of logic, and plans/discussionstarter for that

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/24/2011 10:03 AM, Jelte Jansen wrote:
> On 01/21/2011 12:06 PM, Stephen Morris wrote:
> 
>> The first thing should be to step back, look at the components, and define their responsibilities.  E.g. if asiolink is the interface to ASIO - handling the sending and receiving of packets asynchronously - then that is all it should do.  Resolver objects or recursive logic has no place in it.
> 
> 
> that's exactly why i started out describing the things there are now and where
> they are located, as we are still taking this as the base :)
> 
file:///home/jelte/Desktop/sketch.png

This is what i'm thinking of (though it may be a bit oversimplified in this
sketch, esp. since it leaves out how callbacks would work). It's actually not
all that different from the current code, except that locations would differ
(and some asio-related things are swept under the carpet).

Resolver is the main program, it calls on asiolink to provide it with an io
context and listeners for udp and tcp (UDPServer and TCPServer in this diagram).

It also sets up a ResolverContext, which does full recursive queries (the
closest current equivalent would be the RecursiveQuery class), which would also
be used by other programs that want to do full recursion/validation/etc.

ResolverContext would create RecursiveLookup objects (current equivalent being
RunningQuery), which perform the actual lookup, and contain the resolver logic
to get from a query to a final answer. It would do so by creating single lookups
(currently objects in the form of UDPQuery, though i hope these need only be
methods), which in turn call into the asiolink to actually send them.

Perhaps we'd also have an extra layer between Resolver and asiolink, come to
think of it (for the actual parsing, scrubbing, and rendering, and for sharing
with Auth)

So a packet would come in on one of the Servers, which would prompt Resolver to
let its ResolverContext start a RecursiveLookup, which would fire off several
SingleLookups through the Senders into the world. The senders call back the
SingleLookup, which would call back the RecursiveLookup, which would either fire
off more, timeout, error, or be satisfied with an answer. In the latter three
cases it would call back through the ResolverContext to the Resolver, which
sends the answer back to whoever asked it in the first place.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk09oDcACgkQ4nZCKsdOncVulQCgzUpdWUizO9XyeR6NUWCZ0AuV
YjoAnjYkIgd1qy2uA0G/aukysmpH7XpY
=JRl2
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sketch.png
Type: image/png
Size: 27390 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110124/783b7440/attachment.png>