On Thu, Dec 02, 2010 at 08:58:20AM +0100, Tommie Gannert wrote:
> William Ahern wrote:
> >> Regarding closing UDP sockets. You can't rebind a socket (if I understand
> >> the man page correctly), so if you want to randomize ports, you'll have
> >> to close/recreate it. And from recent year's injection attacks, I think you
> >> do want to randomize ports.
> >>
> >
> > No, but you can reconnect a datagram socket, which is what matters if you're
> > on the client end. That may be useful depending on the policy, e.g.
> > randomize ports every N queries, possibly keeping a pool of sockets to
> > regain some entropy. (I'm unsure if that's relevant 'cause I've long
> > forgotten the context of the thread.)
> >
> Gliding slightly off-topic, the thread is really about a timeout issue:
>
> Does a re-connect() cause the client socket address to be
> rebound?
No, the socket doesn't get rebound. But I mentioned it because c-ares (at
least the version I have) doesn't bind anything but does use connect on both
tcp and udp sockets.
But I don't think it matters. I keep forgetting that c-ares is just a stub
resolver. I was thinking of the case where c-ares could have been re-using
the same udp socket instead of opening+closing sockets. I think someone
already mentioned ARES_FLAG_STAYOPEN.
I did just test out what happens if you send a datagram on a connected
AF_INET+SOCK_DGRAM socket to a closed port on a remote host; the recv errors
out with ECONNREFUSED (OS X, OpenBSD, and Linux all act the same way). So a
connected UDP socket isn't all that connectionless afterall.
Such an error would cause c-ares to close and skip that server, possibly
causing the whole query to fail. I'm not quite sure what sets error_status
in ares_process.c, other than the ARES_ETIMEOUT in process_timeouts, but
it's certainly possible for ECONNREFUSED (or any socket error, for that
matter) to immediately timeout a query (certainly if a timeout occurred on a
previous host so the error_status was set to that value).
Received on 2010-12-02