[an error occurred while processing this directive]

HP OpenVMS Systems

ask the wizard
Content starts here

TCP/IP C gethostbyname delays and DNS?

» close window

The Question is:

 
Digital TCP/IP QIO programming questions (using UCX v4.2, would apply to
all though).
 
I am using a QIO IO$_ACPCONTROL with INETACP_FUNC$C_GETHOSTBYNAME to
retrieve a host address from a name.  It works fine!
 
However, sometimes it can return within a few seconds with host unknown,
but then a few seconds later return the host address, after which it
works consistently for quite a while, then may exhibit this one-off
behaviour again.  I am putting this down to DNS host name resolution
latencies, where DNS is querying other up-stream servers for information
that is taking some seconds (perhaps tens of seconds) to ultimately be
resolved.
 
My questions are these ...
 
Does the QIO ACP have a fixed (or perhaps set-able) timeout period after
which it returns whether it has received an answer from the DNS or not?
 
Should I expect this behaviour and allow for it, perhaps by retrying a
number of times or for an extended period before reporting the unknown
host?
 
If so, is there some discriminant in UCX that I can use to determine
whether the status returned from the ACP QIO represents an authoritative
DNS reply or just some lack of response within a defined period?
 
Sorry if this is a little long-winded.  I don't seem to be able to set
up a test environment where I can replicate the reported problem.
 
Thanks in advance (again :^)  Mark Daniel.
 
 


The Answer is :

 
  Your observations make sense, based on the expected behavior of the
  ACPCONTROL supporting code, the code that looks up the hostnames.
  When you issue that sys$qio call, you are asking the INETACP process
  to look up the host name for you, rather than looking it up in your
  own process context.  The ACP thus waits, unable to process any other
  events, whilst waiting for a response from the nameserver.  To prevent
  a more general hang across other ACP clients, the INETACP waits for one
  second for an answer, and then times out.  No retries are performed.
 
  When resolving the name of a faraway host, it may take much longer than
  one second to return a response from the remote nameserver responsible
  for that host.  In that case, the first lookup will fail, but a subsequent
  attempt -- say one made twenty seconds later -- will work because by the
  time of the second request, you local nameserver will have the appropriate
  records cached.
 
  As a general rule, it is better to call gethostbyname() yourself or
  otherwise case the lookup to use your local cache, rather than issuing
  the ACPCONTROL QIO and asking the INETACP to perform the lookup for you.
 

answer written or last revised on ( 30-APR-1999 )

» close window