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.