On 8/8/2019 7:34 AM, Tony Garnock-Jones wrote:
On Tue, 6 Aug 2019 at 21:15, George Neuner <gneun...@comcast.net
<mailto:gneun...@comcast.net>> wrote:
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.
Those states only apply to TCP sockets; UDP is stateless (in that
way). It still seems quite peculiar to me that UDP sockets should
outlive their process, under any circumstances. Perhaps it's a
Mac-specific thing? I wonder if it's a bug or if it's for some reason.
That's not exactly true - UDP is "stateless" only when compared to streams.
The datagram protocol is itself a state machine, and there are a number
of modes that UDP sockets can be in, including "half-closed": e.g., you
can call *shutdown* on a UDP socket to individually block either its
send or receive capabilities. Also, you can call *connect* on a UDP
socket and then use *read*, *write*, *send* and *recv* in lieu of the
stateless *sendto* / *sendmsg* or *recvfrom* / *recvmsg*. I.e. there is
both the notion of "unconnected" and "connected" UDP, although
"connected" means something different here than it does with TCP.
I've been programming so long that most of my sources are dead trees on
a bookshelf. Google is not being particularly helpful just now in
finding a comprehensive socket reference to cite ... unless you want PDF
books or the original RFCs. It seems much of the online information on
UDP is in bits and pieces, and most of it deals only with "unconnected"
use. But you can search "*connected udp*" for a few starting points.
I'm not sure what, if anything, netstat can show for "connected" or
"half-closed" UDP sockets - I'm don't think network stack makes any of
that information available to be queried. It's much more concerned with
the more complex TCP status.
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/639b088b-ef38-bdf9-0302-96818dcf3bf9%40comcast.net.
