Disconnect() does not return TIMEOUT error

Question

Hello. Consider the following scenario: TCP, client vs server client sends disconnect to server (FIN) server replies with ACK till here it OK server is stuck for some reason (simulated by a breakpoint in the server app) server does not send FIN to client (as supposed) client never changes its socket to close (as it hasn’t received a FIN from the server) client’s socket is in FIN_WAIT (= 0x18) state client is stuck in an infinite loop in the disconnect() func | | V Can you please help fixing the bug? Thanks, Aviv

avivf · Answer

Hello, I’ve been reading your reply. You mentioned that in a server application it’s better to use close() rather than disconnect(). What if my application in a client instead of a server. Should I still use close() rather than disconnet()? What is the actual difference between close() and disconnet()? When disconnet() is to be used? Thanks, Aviv

Coccoliso · Answer

The disconnection process involves communication with the peer with ACK / FIN exchanges and can be Active or Passive ( depends on connected peer ). In any case, at the end of the disconnection, the status Sn_SR always passes in SOCK_CLOSED and it is quite hard to find SOCK_CLOSING, SOCK_FIN_WAIT or SOCK_LAST_ACK for the speed with which move from one state to another. I noticed that in LAN is very difficult to read these intermediate states and if you wait a disconnect you get lost forever in an intermediate state while if you connect through internet is quite repeatable.

avivf · Answer

Hello, I’ve been reading your reply. You mentioned that in a server application it’s better to use close() rather than disconnect(). What if my application in a client instead of a server. Should I still use close() rather than disconnet()? What is the actual difference between close() and disconnet()? When disconnet() is to be used? Thanks, Aviv

Coccoliso · Answer

In client or server application the problem remains… In a communication with an http server where once you’ve sent the request and received the answer instead of making a DISCONNECT for as mentioned above should make a CLOSE to prevent the ACK / FIN that in any case occur even in this case. In case of communications with continuous flow at the end does not make DISCONNECT but simply make a CLOSE.