Subject: Re: Info about Full resolver

From: Kevin Darcy <[email-masked]>
Date: Mon, 31 Jan 2000 22:03:47 -0500

SRINIVASU V V S wrote:

> hi all,
>   i am  implementing  full resolver  and  stub resolver..
>   my doubts are as follows:
>   1) i think a full resolver needs to be as a separate task ... but is
> there any need for a stub resolver also to be a separate task.. i have seen
> so many stub resolvers running under the applications context..
>
>   2) If u want to implement TCP queries how it will be efficient in case of
> full resolver, in which it has to contact so many name servers for a single
> query.. one more,  there is a facility like TCP (stayopen) in LINUX .. can
> we implement this in Full resolver
>
>  kindly clear my doubts
>
> thanx and regards,
> srini

A full resolver wouldn't *necessarily* have to run as a separate task; one
could theoretically co-ordinate the use of system resources, including a
centralized name cache and UDP/TCP port usage, between multiple tasks. But
most implementors find it easier and more versatile to just run a
"caching-only" nameserver accessed by stub resolvers, than to implement a
"full" resolver.

What value would there be in running the stub resolver as a separate task,
given, as above, the option of running a caching-only nameserver as a separate
task instead?

I don't really understand the first part of question (2): like stub resolvers,
full resolvers would presumably use UDP whenever possible, for efficiency.
Even if *forced* to use TCP, I don't know that it would usually be
advantageous for them to keep the connections open; typical nameserver-usage
patterns are so diverse, that such a resolver might incur more overhead
keeping the connections open (keepalives and whatnot) than it would building
them and tearing them down again "on demand". Besides, I think most nameserver
implementations will shut down the TCP connection on the server-side once the
answer is given.

- Kevin

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.