|
Home > Archive > Unix Programming > March 2007 > gethostbyname + timeout
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
gethostbyname + timeout
|
|
|
| Hello,
I need to add timeout to gethostbyname function in my program. I
googled and searched archives, found some examples with alert(), but
can't make it work :/ I would be grateful of someone could tell me how
to do it.
| |
| William Ahern 2007-02-01, 1:24 am |
| On Wed, 31 Jan 2007 15:15:42 -0800, ultr wrote:
> Hello,
>
> I need to add timeout to gethostbyname function in my program. I
> googled and searched archives, found some examples with alert(), but
> can't make it work :/ I would be grateful of someone could tell me how
> to do it.
You can't. Or rather, you shouldn't.
The trick with alarm(2) (not alert()), is to longjmp(3) from the signal
handler to a context created with setjmp(3) before calling gethostbyname(3).
This is, unfortunately, very common in PERL code (in PERL die() actually
uses longjmp() internally to a context set from an eval statement).
However, gethostbyname() keeps internal state, and afterward its unsafe
to call the function again. gethostbyname_r() might be relatively safer,
but you've probably also leaked a file descriptor and memory,
meaning you could only do it so many times from a single process before it
won't work anymore. (And from a strict C perspective, jumping from the
signal handler itself is questionable.)
You do have options.
1) Multiple processes. Use child processes and the
gethostbyname()+alarm() trick, and return the answer down a pipe to
the parent. The child will just kill itself if it timeouts (or
alternatively the parent will set the alarm and kill the child), since it
cannot reliably do it's job afterward.
2) Use threads in conjunction with gethostbyname_r(), or preferably
getaddrinfo(3). Still, you cannot interrupt these functions within the
thread, and so you have a few more decisions to make in terms of how you
handle timeouts.
3) Use a third-party asynchronous DNS library: ADNS, C-Ares and UDNS are
the first ones which comes to mind, the former two probably being the most
popular.
| |
| David Schwartz 2007-02-01, 1:24 am |
| On Jan 31, 3:15 pm, "ultr" <piotrdabrowski.u...@gmail.com> wrote:
> I need to add timeout to gethostbyname function in my program. I
> googled and searched archives, found some examples with alert(), but
> can't make it work :/ I would be grateful of someone could tell me how
> to do it.
It's hard to imagine this is really what you need. Either you have
something else to do while waiting for the resolve to complete or you
don't. If you don't have anything to do, what good is a timeout before
the resolve attempt actually times out? If you do have something else
to do, why wait until the timeout to do it?
DS
| |
| Christopher Layne 2007-02-01, 1:24 am |
| David Schwartz wrote:
> It's hard to imagine this is really what you need. Either you have
> something else to do while waiting for the resolve to complete or you
> don't. If you don't have anything to do, what good is a timeout before
> the resolve attempt actually times out? If you do have something else
> to do, why wait until the timeout to do it?
>
> DS
Good points. He should also be aware that depending on the TTL of records he
is requesting, after the first lookup they will remain cached by the local
resolver until the TTL decays.
If this is for a gui or interactive code, it most definitely should be using
some kind of threading or async library like C-Ares.
| |
| Christopher Layne 2007-02-01, 1:24 am |
| Also, stay away from gethostbyname() and any of it's devil child variants. Use
getaddrinfo() and getnameinfo().
| |
| Rainer Weikusat 2007-02-01, 7:22 am |
| "ultr" <piotrdabrowski.ultr@gmail.com> writes:
> I need to add timeout to gethostbyname function in my program.
I assume that you want to do a DNS lookup. DNS is a UDP-based
protocol, which means the the library implementation will do a limited
amount of query retries to available servers (I am additionally
assuming a stub-resolver intended to consult a recursive server),
timeout on its own and return with h_errno == TRY_AGAIN. It is often
not sensible to use a shorter timeout than the default (for instance,
an interactive application should rather offer the possibility to
interrupt long running task than to just give up, effectively
dictating a user how patient he has to be).
The only portable and reliable way to implement such a timeout would
be using a killable child process to do the lookup and to kill it
after 'too much' time has expired.
| |
| Rick Jones 2007-02-01, 1:18 pm |
| Rainer Weikusat <rainer.weikusat@sncag.com> wrote:
> I assume that you want to do a DNS lookup. DNS is a UDP-based
> protocol,
It would be more accurate to say "DNS queries are generally carried in
UDP datagrams"
DNS queries _can_ be carried over TCP connections, it just doesn't
happen all that often. And other "DNS things" regularly happen over
TCP connections.
rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... 
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
| |
| Rainer Weikusat 2007-02-01, 1:18 pm |
| Rick Jones <rick.jones2@hp.com> writes:
> Rainer Weikusat <rainer.weikusat@sncag.com> wrote:
>
> It would be more accurate to say "DNS queries are generally carried in
> UDP datagrams"
>
> DNS queries _can_ be carried over TCP connections, it just doesn't
> happen all that often. And other "DNS things" regularly happen over
> TCP connections.
RFC1035 says:
The DNS assumes that messages will be transmitted as datagrams
or in a byte stream carried by a virtual circuit. While
virtual circuits can be used for any DNS activity, datagrams
are preferred for queries due to their lower overhead and
better performance.
[...]
UDP is not acceptable for zone transfers, but is the
recommended method for standard queries in the Internet.
IMO, calling the DNS protocol 'UDP-based' is appropriate because of
this and because simplifications tend to make things simpler to
explain (and understand).
| |
| David Schwartz 2007-02-04, 7:20 am |
| On Feb 1, 10:20 am, Rainer Weikusat <rainer.weiku...@sncag.com> wrote:
> RFC1035 says:
>
> The DNS assumes that messages will be transmitted as datagrams
> or in a byte stream carried by a virtual circuit. While
> virtual circuits can be used for any DNS activity, datagrams
> are preferred for queries due to their lower overhead and
> better performance.
I think you may be misunderstanding what this paragraph is saying.
It's saying that this assumption is made in the design of the
protocol, that is, the protocol is designed to always correctly handle
loss of packets. It's not saying that in the real world DNS will
actually be transmitted as datagrams. It's simply giving one of the
assumptions that the protocol design proceeded with.
> UDP is not acceptable for zone transfers, but is the
> recommended method for standard queries in the Internet.
> IMO, calling the DNS protocol 'UDP-based' is appropriate because of
> this and because simplifications tend to make things simpler to
> explain (and understand).
I think it's dangerous. TCP is supposed to be equally supported and
saying things like this may mislead people into thinking they are not
requires to support queries over TCP in a server or are not allowed to
perform such queries in a client.
DS
| |
| Rainer Weikusat 2007-02-04, 7:21 pm |
| "David Schwartz" <davids@webmaster.com> writes:
> On Feb 1, 10:20 am, Rainer Weikusat <rainer.weiku...@sncag.com> wrote:
>
> I think you may be misunderstanding what this paragraph is saying.
> It's saying that this assumption is made in the design of the
> protocol, that is, the protocol is designed to always correctly handle
> loss of packets.
That what be an not entirely unreasonable guess based on the first
sentence of the cited text. But the DNS protocol does not deal with
packet loss and the actually important part is in the second sentence:
[...], datagrams are preferred for queries due [...]
> It's not saying that in the real world DNS will
> actually be transmitted as datagrams.
Actually, no. It demands the DNS queries/ responses should be
transmitted as datagrams and 'usual implementation' do this.
>
>
> I think it's dangerous. TCP is supposed to be equally supported and
> saying things like this may mislead people into thinking they are not
> requires to support queries over TCP in a server or are not allowed to
> perform such queries in a client.
It is likely that implementations of anything done without knowing the
specification behave strangely in various respects, although this has
not yet stopped anyone from implementing them or prevented those
implementations from being 'fairly successful' (busybox) or
'commercially viable' (eg what Conexant-DSL-modems call 'telnet' --
the most original idea being the use of LFCR as line terminator).
But this is not really relevant in the context of understanding the
behaviour of a 'usual' C-library stub resolver, called via one the
various defined frontends (like gethostbyname).
| |
| Rainer Weikusat 2007-02-04, 7:21 pm |
| "David Schwartz" <davids@webmaster.com> writes:
> On Feb 1, 10:20 am, Rainer Weikusat <rainer.weiku...@sncag.com> wrote:
>
> I think you may be misunderstanding what this paragraph is saying.
> It's saying that this assumption is made in the design of the
> protocol, that is, the protocol is designed to always correctly handle
> loss of packets.
That would be an not entirely unreasonable guess based on the first
sentence of the cited text. But the DNS protocol does not deal with
packet loss and the actually important part is in the second sentence:
[...], datagrams are preferred for queries due [...]
> It's not saying that in the real world DNS will
> actually be transmitted as datagrams.
Actually, no. It demands the DNS queries/ responses should be
transmitted as datagrams and 'usual implementation' do this.
>
>
> I think it's dangerous. TCP is supposed to be equally supported and
> saying things like this may mislead people into thinking they are not
> requires to support queries over TCP in a server or are not allowed to
> perform such queries in a client.
It is likely that implementations of anything done without knowing the
specification behave strangely in various respects, although this has
not yet stopped anyone from implementing them or prevented those
implementations from being 'fairly successful' (busybox) or
'commercially viable' (eg what Conexant-DSL-modems call 'telnet' --
the most original idea being the use of LFCR as line terminator).
But this is not really relevant in the context of understanding the
behaviour of a 'usual' C-library stub resolver, called via one the
various defined frontends (like gethostbyname).
| |
| Bin Chen 2007-03-02, 1:22 am |
| On 2=D4=C21=C8=D5, =CF=C2=CE=E712=CA=B144=B7=D6, Christopher Layne <cla...@=
com.anodized> wrote:
> Also, stay away fromgethostbyname() and any of it's devil child variants.=
Use
> getaddrinfo() and getnameinfo().
What is the advantages that getaddrinfo() over gethostbyname()? From
the man pages it only emphasizes getaddrinfo() is thread safe, seems
no direct relation to the OP's question that concerns timeout feature.
| |
| Rainer Weikusat 2007-03-02, 7:20 am |
| "Bin Chen" <binary.chen@gmail.com> writes:
> On 2月1日, 下午12时44分, Christopher Layne <cla...@com.anodized> wrote:
>
> What is the advantages that getaddrinfo() over gethostbyname()? From
> the man pages it only emphasizes getaddrinfo() is thread safe, seems
> no direct relation to the OP's question that concerns timeout feature.
In the context of the quote you are referring to: gethostbyname and
gethostbyaddr are interface that were designed in the 1980's and the
academic theory wrt how a sensible tradeoff should look like has
changed quite a lot since then.
There are no real practical advantages if the functionality is
sufficient.
| |
| Bin Chen 2007-03-02, 7:20 am |
| On Mar 2, 5:26 pm, Rainer Weikusat <rainer.weiku...@sncag.com> wrote:
> "Bin Chen" <binary.c...@gmail.com> writes:
..=2E.@com.anodized> wrote:[vbcol=seagreen]
ts. Use[vbcol=seagreen]
>
>
> In the context of the quote you are referring to: gethostbyname and
> gethostbyaddr are interface that were designed in the 1980's and the
What's the matter of my quote?
| |
| Rick Jones 2007-03-02, 7:16 pm |
| Bin Chen <binary.chen@gmail.com> wrote:
> On 2??1??, ????12??44??, Christopher Layne <cla...@com.anodized> wrote:
[vbcol=seagreen]
> What is the advantages that getaddrinfo() over gethostbyname()? From
> the man pages it only emphasizes getaddrinfo() is thread safe, seems
> no direct relation to the OP's question that concerns timeout feature.
getaddrinfo() includes support for IPv6 addresses and simultaneous
servicce lookups. It also fills-in sockaddr structures more directly
and allows one to pass them to calls such as bind(), or connect()
without further ado.
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
|
|
|
|
|