site_archiver@lists.apple.com Delivered-To: macnetworkprog@lists.apple.com There are two cases here. The specified option is invalid at the specified socket level or the socket has been shut down. <http://www.opengroup.org/onlinepubs/009695399/functions/setsockopt.html> <http://developer.apple.com/bugreporter/> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ 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.... At 10:53 +1300 31/1/08, Glenn Anderson wrote: 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. A. accept returns a valid address and setsockopt fails afterwards -- This seems like reasonable behaviour on behalf of the kernel. It gave you back a valid socket but the socket shut down before you called setsockopt. The standard specifically states that EINVAL can be caused by: I suspect that the UNIX '03 conformance changes are the reason why you're seeing different behaviour on 10.4 vs 10.5. B. accept returns a null address -- This smells like a bug to me. Definitely Radar-worthy IMHO. Please send me the bug number. Also, if you can include code that reproduces the problem, that will definitely improve the chances of it getting fixed (-: 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? I expect that your best bet is <x-man-page://2/getpeername>. This is traditionally used by sockets code to test whether a connection is in place. For example, when doing non-blocking connects, you typically use getpeername to determine whether the connect succeeded or failed. This email sent to site_archiver@lists.apple.com