Some protocols use the TCP handshaking as the application handshaking, violating the OSI layers. Many of them, handmade. Others, official, as HP 9100. For instance, an application may need only control events as Start of connection and End of connection, and the programmer may think that the TCP similar events will be useful instead of thinking application control messages for those events.
If someone follows the usual guidelines on TCP connection termination, he may found unexpected problems related to data loss.
One side active closes, and sends a FIN. The other side sends ACK (enters the CLOSE_WAIT state), and then when needed actively closes the connection sending a FIN to the termination initiator, waiting its ACK, and then considering the connection closed in both sides. On BSD you may think of the call close() for active close.
First consideration: the state diagram doesn't show the state changes related to data transmissions.
From 4.2.2.13: If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost.
This, in fact, means that you will NOT receive a FIN, if the other side application actively closes the connection without having received the incoming data. The stack will send a RST. This potentially introduces data loss.
You can consider these two possible additional meanings for these sent messages:
Let's assume the programmer wants to rely on the TCP handshake for sending some data. He doesn't know if the other side will send anything:
The programmer made a big error between the send() and the close() calls: if the other side sends some data, and this side doesn't recv() it, it will send a RST instead of a FIN. If the other side TCP/IP stack receives that RST, it will throw away all the data the application still hasn't recv().. Data loss.
Don't violate the OSI layers, and think a handshake for your application communication.
2007 Lluis Batlle i Rossell (with help from Thomas Wyatt) - viric@vicerveza.homeunix.net