On 08/07/13 15:25, W.C.A. Wijngaards wrote:
I also think it would be good to alleviate this issue. It's polite
to the network and other hosts to properly receive reply packets to
your own requests, even if you no longer need them.
The packets have timed out. We do not expect them any longer. A
retry is probably sent over another port number (randomised) and thus
uses a different socket.
I do not know how to do what you ask - keep the port open for a reply
that arrives later than expected, in a way that is good for
performance and on resources.
Fair enough; if it's not possible in any sensible way, then it's not
possible.
FWIW I do acknowledge the issues you raise; it is entirely possible
there is no nice solution, other than what's already being done.
AFAIK there's no "/dev/null" for UDP sockets, though maybe you could
emulate one by setting the SO_RCVBUF as small as possible and dropping
it from the select/poll/epoll loop, with a close queued for some future
time. But that'll probably still consume kernel resources. Whether this
is a significant concern, I couldn't say - presumably you only have to
"slow close" sockets that didn't receive a reply, which should be in a
minority.
It could be more complicated than it's worth.
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
