[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV dns lookups
From: |
Foteos Macrides |
Subject: |
Re: LYNX-DEV dns lookups |
Date: |
Mon, 22 Dec 1997 13:03:18 -0500 (EST) |
Andy Harper <address@hidden> wrote:
>>> I discovered the following problem while using LYNX compiled with the
>>> socketshr
>>> library for VMS to access a service provided by the british library:
>>>
>>> Despite the name (opac97.bl.uk) resolving to an IP address, lynx fails to
>>> connect with:
>>> "unable to access remote host!"
>>
>>I've managed to connect fairly quickly to opac97.bl.uk using Lynx version
>>2.7.1
>>with some of Fote's modifications installed. We're using MultiNet v4.0A under
>>OpenVMS 6.2 on a VAX.
>
>
> well exactly, so what is socketshr doing that is different? Does the multinet
> gethostbyname routine NOT fail if it cannot do the reverse lookup? I shal
> obviously have to write a short test program!
Empirically (i.e., looking at the HTParseInet() phost structure
with the debugger), MultiNet is loading the name argument of the
gethostbyname() call into phost->h_name, e.g., for www.wfbr.edu it becomes
that, not sci.wfbr.edu. I don't see why any of that matters, because
Lynx doesn't use the phost->h_name element, and if you can tweak the
socketshr library's gethostbyname() such that it loads its name argument
and returns a valid pointer if the other elements are valid, it should
work as with MultiNet.
Fote
=========================================================================
Foteos Macrides Worcester Foundation for Biomedical Research
address@hidden 222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================