Socket programming, what about "CLOSE_WAIT", "FIN_WAIT_2" and "LISTENING"? - c++

Question

I am writing a socket based C application which seems to behave in a very unstable way.
The code is standard socket handling on TCP port 6683, and I know it has worked before. Instead of mentioning the source code, I believe the most interesting are the results of the netstat -aon command:
When it worked fine, the results of the netstat -aon| grep 6683 command were:
TCP 127.0.0.1:6683 127.0.0.1:50888 CLOSE_WAIT 6128
TCP 127.0.0.1:50888 127.0.0.1:6683 FIN_WAIT_2 3764
When it does not work anymore, the results of the netstat -aon | grep 6683 command are:
TCP 127.0.0.1:6683 0.0.0.0:0 LISTENING 7800
Does anybody know the meaning of the mentioned "netstat" results, what this might mean for the socket handling and what can I do in order to return to the situation giving the first results?
Thanks

Answer 1

From Microsoft's Support Website:
FIN_WAIT_2 Indicates that the client just received acknowledgment of the first FIN signal from the server
LISTENING Indicates that the server is ready to accept a connection
CLOSE_WAIT Indicates that the server has received the first FIN signal from the client and the connection is in the process of being
closed
Based on the above, you know that in your first case the server has received the client's FIN, and the client has received the ACK from sending the FIN to the server.
However, in the second case the server is ready to accept a connection, which to me sounds like you haven't established your TCP connection yet.
Without really knowing what your C program is trying to do, it's hard to diagnose your issues here, but I would take a look at the documentation for netstat and go from there.

Answer 2

From the netstat documentation :
FIN_WAIT2
Connection is closed, and the socket is waiting for a shutdown from the remote end.
CLOSE_WAIT
The remote end has shut down, waiting for the socket to close.
The LISTENING state is just the server socket waiting for clients. This is a normal behavior for a listening server socket (which is not the same as the connection server socket).
You can see that the side with FIN_WAIT2 is closed and waiting for the other, but the side with CLOSE_WAIT, is currently closing, but not yet closed. Based on the LISTENING socket, the client is closed, and the currently closing side is the server. The server is probably waiting because there is data to read that was not yet read. It can't close the socket without data loss, which is unacceptable for TCP. The connection should close normally after all the data left on the server side is read.

Answer 3

Thanks for the fast responses. Meanwhile I have found what was going wrong:
My application was a server application, creating a client process, and setting up a TCP socket for communicating with that client process (which was done using the C commands:
snprintf(buf, 1024, "client_process.exe %s %d", szListenHost, iListenPort);
CreateProcess(NULL, buf, NULL, NULL, FALSE, dwCreationFlags,
NULL, NULL, &sin, &pin);
Sometimes this went fine, sometimes not, based on the place from where I launched my server process: when I launched it from the official directory, it was working fine. When I launched it from my development environment, it was not working.
The reason for this was very simple: in my development environment, the "client_process.exe" file was not present in the current directory.
I have now copied the "client_process.exe" into that directory and added an extra check:
int return_value = CreateProcess(NULL, buf, NULL, NULL, FALSE,
dwCreationFlags, NULL, NULL, &sin, &pin);
if (return_value == 0) {
printf("The client_process.exe has not been started successfully.\n");
word error_return_value = GetLastError();
printf("The corresponding error value is:[%d]\n", error_return_value);
if (error_return_value == 2) {
printf("The client_process.exe is not present in the current directory.\n");
}
}
Kind regards