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.
There are two cases here.
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:
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macnetworkprog/email@hidden
