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.
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.
Hi,
It is upto you what is used close() or disconnect(). If you want to be safe closed the channel, You’d like to use close(). And if you don’t need to be safe closed the channel.
The difference close() from disconnect(),
While disconnect() requests the peer to close the channel, close() is not request the the close the channel.
In disconnect() processing is as following
NodeA NodeB
FIN------------>
<----------ACK
<----------FIN
ACK----------->
In close() processing is no need FIN & ACK packets. So, Just only own the channel is closed, The peer’s channel is still connected.