yvan wrote:
Hi,
Here is my client/server scenario:
Step1: Client connects to server and sends data sucessfully (using
Socket.Send()).
Step2: Server gracefully exists (calls Socket.Shutdown() and
Socket.Close()). I see the server connection status go from ESTABLISHED to
FIN_WAIT2, the client connection go from ESTABLISHED to WAIT_CLOSE.
Step3: client.Send() succeeds and return the number of bytes sent (over the
closed connection!)
Step4: same as step3, Send() throws, which is expected, but was expected in
step3
Question 1: Shouldn't step3 behave like step4? If step3 can happen, then the
transport is not reliable.
Question 2: Is there a socket status event the client can subscribe to?
....
This is by design of TCP protocol.
What you describe is not graceful close by server. In CLOSE_WAIT state,
send is allowed. CLOSE_WAIT means that other side has shutdown it's
outgoing side of connection (you will not receive any data on that
connection), but you may send until you shutdown your side (remember
that tcp is full-duplex). Server should not exit or call close on socket
until it has receive shutdown from other side (it has to make transition
from FIN_WAIT2 to TIME_WAIT state).
Gracefull close is:
Server calls Shutdown with SD_SEND
client receives close notification (read will return 0)
client may send data and call shutdown with SD_SEND when finished
server must loop in read until it receives close notification (receive 0
from read). Only then it may close socket.
Only if you close gracefully, you are sure data is delivered. Please
note that there are linger options that can be set which affect this
Check in MSDN:
http://msdn.microsoft.com/library/de..._closure_2.asp
Send does not ensure data is sent, it ensures only it is buffered by the
OS (TCP protocol). IOW, number of bytes returned from send call > 0 does
not mean data is received by other side.
Regards,
Goran
