[erlang-questions] is inet:gethostbyname( IP ) correct?
Fri Oct 16 12:13:22 CEST 2009
On Thu, Oct 15, 2009 at 04:48:38PM +0100, Robert Raschke wrote:
> On Thu, Oct 15, 2009 at 4:28 PM, Raimo Niskanen <
> > wrote:
> > On Thu, Oct 15, 2009 at 03:02:40PM +0200, info wrote:
> > > Dear Raimo,
> > > I can resume: I discovered that gethostbyname call inet_gethost.c
> > > I don't understand inet_gethost.c :-(
> > > Where "goes" this problem for finding the information ?
> > > If we know where and what, we could perhaps find what is missing in my
> > windows 2003 ...
> > > Hope to read you soon !
> > > John
> > Well, there is not much more to say. inet_gethost.c calls
> > struct hostent *gethostbyname(const char *name) in the
> > winsock2 library:
> > http://msdn.microsoft.com/en-us/library/ms738524(VS.85).aspx<http://msdn.microsoft.com/en-us/library/ms738524%28VS.85%29.aspx>
> > It never returns.
> > It is deprecated but that does not mean broken.
> > I have a Windows 2003 server that it works on.
> > We have not found the reason it differs between
> > my server and your server.
> > And that is about it.
> I can consistently reproduce the hanging gethostbyname() in inet_gethost.exe
> on Windows 2003 when I have the 'Microsoft Firewall Client for ISA Server
> Version 4.0' installed. This is a specific add-on, nothing to do with
> Microsoft Firewall in your Network Properties.
> If I remove it, it works fine, if I add it it hangs. Apart from that the
> W2003 build is as vanilla as it gets.
This rings a bell for our Windows guys.
Firewall software on Windows do nasty things. They e.g replace
the Winsock API for other applications so things you had to do
before suddenly breaks. Especially since inet_gethost.exe
does calls from worker threads the API replacement may mess up.
We have had hanging gethostbyname() for certain firewalls.
We will install virtual a Windows 2003 server machine,
the Microsoft Firewall Client for ISA Server seems to be
from Microsoft, but where to find, if we need, the Microsoft ISA Server
I do not know...
Then we will try to reproduce the problem.
> Nothing much to go on, but I would not be surprised if some system DLL is
> getting in the way. This is very hard to diagnose.
> One day I'll get around to compiling inet_gethost.exe in my setup, just to
> rule out poor linkage due to the VC++ setup used to build the shipping
> executables. If I compile up a trivial gethostbyname() example from MSDN, it
> works OK in all circumstances.
> There are a few strange dependencies in other shipped Windows files, for
> example beam.dll seems to depend on a particular MSVCR80.DLL with the
> version 8.0.50727.1433 . And if you have an older Windows machine, you get
> the completely unhelpful popup box telling you that your program could not
> be run. This has something to do with Windows Side-by-Side DLL deployment,
> and I completely fail to grasp what that's all about.
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions