Re: Nameserver calls - libesmtp problem?

On 2001.06.21 20:17:15 +0100 Albrecht Dreß wrote:

> ...but tcpdump shows me that it tries to connect to the nameserver to
> look up localhost when hitting the `send' button in balsa:
> This does *not* hapen if i just say `ping localhost' - it pings without
> dialing...
> To be absolutely sure, I wrote a microscopic C program which calls
> gethostbyname, and again with localhost, it does *not* try to connect to
> the nameserver (as it does for e.g.

I use gethostbyname_r() in libESMTP since it is thread safe.

> Arrrrgh! Maybe I am just too dumb for all this?!? What the hell *did* I
> mix up here???

I'm stumped just now.  All I can think of is that maybe gethostbyname()
and gethostbyname_r() differ in that the former does the hosts,bind thing
but gethostbyname_r() is a stub resolver.  I don't have the source to
GNU libc so I can't confirm this.  As I understand it, on recent Solaris
versions, gethostbyname() just calls through to gethostbyname_r() but
maybe I'm stupid to assume all implementations would do this.
Perhaps you should try your program using gethostbyname_r() and see
what difference that makes.  FWIW, I use the resolver functions fairly
much like most other programs that use them do, i.e. trusting them
to do the Right Thing and not hard coding special cases like localhost.

I notice that the rest of the Balsa code uses gethostbyname() so it's
possible that libESMTP is doing something subtly different to the rest
of the Balsa code.  Incidentally that needs attention; since Balsa is
threaded code using gethostbyname() is dangerous.

Having said all that, the exact behaviour of gethostbyname + variants
is implementation dependent so even solving this case leaves the solution
for other platforms indeterminate.  I figure the only safe strategy is to
run a name server on the local host or somewhere on the local network
and make sure applications use *only* stub resolvers.

(If you think all that is bad, the implementation of gethostbyname() in
Winsuck thinks that NETBIOS names should be used but only if name server
queries time out, and unlike the other versions I know of, doesn't handle
IP address literals!)

I will look into using one of the more modern resolver APIs.  The
lightweight resolver library that comes with the bind 9 distro or
the IPv6 safe functions (getipnodebyname or something like that
I think) come to mind.  Both of these alternatives are thread safe,
so perhaps the main Balsa code should use them too.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]