Joachim Worringen wrote:
> after checking Stevens, Google etc. and not finding an answer, I try it
> here: when doing a non-zero sized send() on a socket in state
> CLOSE_WAIT, what is the expected result?
It depends. If this is the TCP half close scenario (can
be done by shutdown(SHUT_WR), the side in CLOSE_WAIT can
keep on sending until it is done. And if this is not the
half close scenario, meaning the peer has really close()
the connection, the first send() (assuming there is no
data in transit before that) will still return success.
But when the data arrives at the peer, it will send a RST.
So the next send() will return EPIPE (assuming the RST has
arrived).
> My test program shows me the
> "success" for i.e. a send of 128 bytes for a standard Ethernet-based socket.
>
> Our socket implementation, however, uses direct remote memory access
> (using our own interconnect hardware), and closes this connection if one
> end closes the socket. This results in a send() on this socket (which
> still is in CLOSE_WAIT, though) return EPIPE (plus SIGPIPE signal).
Suppose you are trying to emulate a TCP socket behavior.
Then I think you need to also emulate the half-close
semantics. So if an app does a shutdown(SHUT_WR) causing
the peer to change to CLOSE_WAIT state, the peer should
still be able to keep on sending. And the app can keep
on receiving those data. But if the app close() the socket,
I guess it is OK for the peer to get EPIPE immediately for
the first send().
> The behaviour on close() with respect to SO_LINGER is a different
> aspect, right?
If an app sets the SO_LINGER option, it means that it wants
the close() to wait until all the sent data has been ack'ed
by the peer or until the specified period has expired. So
it is not really related to the question above.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
