I write portable Windows/Linux application that uses sockets. I use gethostbyname
function to perform DNS lookups.
However, I don't see how to set gethostbyname
timeout and secure my application against hanging during name lookup.
Of course, it is possible to run gethostbyname
on another thread, and that what I do. However, it is solution for trivial applications only.
My application uses 1000-3000 connections in parallel. In such situation the question is: what to do with timeouted threads? I don't see good solution. We can "forget" them, however, we are at risk that our program threads count will grow up to infinity on bad networks. We can terminate them, but the idea looks terrible. From my experience, Windows can crash after thousands of threads termination, and I don't know how Linux will behave in such conditions.
Also, thread creation needs many resources; it is not good idea to create 3000 threads just to run gethostbyname
function and exit.
So, separate thread doesn't look like good idea for really complex application. Another alternative is to write own DNS client of course, however, it also doesn't look good.
Is there any "official" way on Windows and Linux (or better portable way) to get host address with custom timeout?
First of all: don't use gethostbyname()
, it's obsolete. Use getaddrinfo()
instead.
What you want is asynchronous name resolution. It's a common requirement, but unfortunately there is no "standard" way, how to do it. Here my hints for finding the best solution for you:
Don't implement a DNS client. Name resolution is more than just DNS. Think of mDNS, hosts files and so on. Use a system function like getaddrinfo()
that abstracts the different name resolution mechanisms for you.
Some systems offer asynchronous versions of the resolution functions, like glibc offers getaddrinfo_a()
.
There are asynchronous resolution libraries, that wrap around the synchronous system resolver functions. At first libasyncns comes to my mind.
Boost.Asio supports to use the resolver with a thread pool. See here.