On 8/6/2019 1:54 PM, Tony Garnock-Jones wrote:
On Tuesday, August 6, 2019 at 6:27:51 PM UTC+1, David Storrs wrote:I should mention that the reason I'm looking into this is because I have UDP sockets that are not getting closed. They are managed by custodians, but the custodians are not releasing them; I take this to mean that the custodians are not being run. How can a UDP socket survive process exit?
Sockets belonging to the crashed program are in a "half-closed" state - unable to send, but still able to receive. If you look in netstat you'll find their status is stuck in TIME_WAIT or in SYN or SYN/ACK. There is a delay in cleaning up such "half-closed" sockets. The delay is (derived from) a system wide parameter, and typically the wait time is on the order of 180 seconds.
For most sockets it doesn't matter, but for a receiving "listen" socket, you need to set the SO_REUSEADDR option to be able to reuse the same ipaddr:port combination again without waiting for cleanup. SO_REUSEADDR doesn't actually change the system's cleanup behavior - it simply says that the system can ignore "already exists" errors when trying to create a new socket.
That said ... I thought Racket set SO_REUSEADDR automagically when you create listen sockets.
George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/c43bb573-9722-5a04-240a-004621ea96a5%40comcast.net.
