![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
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.
|