site_archiver@lists.apple.com Delivered-To: macnetworkprog@lists.apple.com Glenn. _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists.... I have run in to some issues with accept() and setsockopt() with TCP port scans. What is happening is over the network is this: C: SYN S: SYN+ACK C: ACK C: RST Sometimes when this happens, accept() returns an address_len of 0. I see this on both Mac OS X 10.4 and 10.5. On Mac OS X 10.5 setsockopt(x, SOL_SOCKET, SO_NOSIGPIPE, ...) also fails with EINVAL in this case. Depending on the timing of the RST, I have also seen a correct address_len from accept() but the subsequent setsockopt() fails. Is accept() returning an address_len of 0 and setsockopt() failing with EINVAL intended behavior? If it is intended, is it documented anywhere? The man pages for these calls definitely don't mention this behavior. While debugging this, I couldn't help wondering if there any way to check the state of a socket to see if the connection has shut down, like OTGetEndpointState under OS 9? Seems like the only way to find out that the connection has shut down is to write to it or read from it, and on 10.5 setsockopt() failing means writing to the socket produces a SIGPIPE. This email sent to site_archiver@lists.apple.com