[erlang-questions] inet_res:getbyname/2 and udp:connect/3

Raimo Niskanen <>
Mon Jun 14 16:01:21 CEST 2010


On Thu, Jun 10, 2010 at 07:10:31PM +0400, Dmitry Belyaev wrote:
> I think, we've found a bug in inet_res.

It seems so.

> 
> It causes request to inet_res:getbyname/2 to respond {error, timeout} if 
> *first* nameserver in /etc/resolv.conf inexistent (or down in my case).

The code apparently gives up on the first {error,timeout},
and that sounds like a bad strategy.

> 
> I couldn't find any info about gen_udp:connect nor erlang:port_get_data/1.
> But commenting following line helped. 
> http://github.com/erlang/otp/blob/dev/lib/kernel/src/inet_res.erl#L676
> 
> query_udp(S, Id, Buffer, IP, Port, Timer, Retry, I, Tm, Verbose) ->
> Timeout = inet:timeout( (Tm * (1 bsl I)) div Retry, Timer),
> ?verbose(Verbose, "Try UDP server : ~p:~p (timeout=~w)\n", [IP, Port, 
> Timeout]),
> %% udp_connect(S, IP, Port),
> udp_send(S, IP, Port, Buffer),
> query_udp_recv(S, IP, Port, Id, Timeout, Verbose).
> 
> 
> Can anyone tell me is it really a bug? And what gen_udp:connect/3 do?

I regard it as a bug. But the correct fix ought to be to recurse
on timeout in inet_res:query_nss_edns/7 and inet_res:query_nss_dns/7,
like for _Error. I will fix it in a future release.



gen_udp:connect/3 calls

    int connect(int socket, const struct sockaddr *address,
              socklen_t address_len);

on the socket. Excerpt from man connect:

    If the initiating socket is not connection-mode, then connect()
    shall set the socket's peer address, and no connection  is  made.  For
    SOCK_DGRAM  sockets,  the  peer  address identifies where all datagrams
    are sent on subsequent send() functions, and limits the remote
    sender for subsequent recv() functions. If address is a null address
    for the protocol, the socket's peer address shall be reset.

i.e default destination is set and reception is limited. I think
it is receiving from only the inteded DNS server that is the purpose.

> 
> -- 
> Dmitry Belyaev
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


More information about the erlang-questions mailing list