On Mon, Nov 29, 2010 at 09:46:21AM +0100, Tommie Gannert wrote:
> Ben Greear wrote:
> > On 11/09/2010 07:43 AM, Brian Yoder wrote:
> >> One thing I did notice was that when a timeout is detected, the UDP
> >> socket should not be closed. UDP is connection-less and oblivious to
> >> whatever issues the server has. But if the UDP socket is closed and then
> >> re-opened (which it shouldn't be), I wouldn't expect any subsequent
> >> error to stick at ARES_ETIMEOUT.
A connectionless socket is not necessarily oblivious. If a datagram is sent
to an unbound port, an ICMP destination [port] unreachable response can be
sent. I'm unsure, though, what effect that might have.
> > Can you sniff to see if any packets are sent after the timeout
> > happens?
> >
> > Can you reproduce by yanking the ethernet cable at an appropriate
> > time to cause a timeout, or maybe adding a network emulator
> > such as netem to cause timeouts?
> >
> > An strace of the program after timeout happens might be nice.
> Brian, have you pursued this further?
>
> 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.)
Received on 2010-12-02