我正在编写一个基于套接字的C应用程序,它似乎表现得非常不稳定。
代码是TCP端口6683上的标准套接字处理,我知道它以前有用。我认为最有趣的是netstat -aon
命令的结果:
当它工作正常时,netstat -aon| grep 6683
命令的结果是:
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
当它不再起作用时,netstat -aon | grep 6683
命令的结果为:
TCP 127.0.0.1:6683 0.0.0.0:0 LISTENING 7800
是否有人知道上述" netstat"的含义?结果,这可能对套接字处理意味着什么,为了返回给出第一个结果的情况,我该怎么办?
由于
答案 0 :(得分:2)
来自Microsoft的支持网站:
FIN_WAIT_2 表示客户刚刚收到来自服务器的第一个FIN信号的确认
LISTENING 表示服务器已准备好接受连接
CLOSE_WAIT 表示服务器已从客户端收到第一个FIN信号,并且连接正在进行中 关闭
基于以上所述,您知道在第一种情况下服务器已收到客户端的FIN,并且客户端已收到将FIN发送到服务器的ACK。
但是,在第二种情况下,服务器已准备好接受连接,这对我来说听起来还没有建立TCP连接。
在不知道您的C程序尝试做什么的情况下,很难在此处诊断您的问题,但我会查看netstat的文档并从那里开始。
答案 1 :(得分:1)
<强> FIN_WAIT2 强> 连接已关闭,并且套接字正在等待远程端的关闭。
<强> CLOSE_WAIT 强> 远程端已关闭,等待套接字关闭。
LISTENING
状态只是等待客户端的服务器套接字。这是侦听服务器套接字的正常行为(与连接服务器套接字不同)。
您可以看到FIN_WAIT2
的一方已关闭并等待另一方,但CLOSE_WAIT
的一方正在关闭,但尚未关闭。基于LISTENING
套接字,客户端关闭,当前关闭端是服务器。服务器可能正在等待,因为有待读取的数据尚未读取。它不能在没有数据丢失的情况下关闭套接字,这对TCP来说是不可接受的。在读取服务器端剩余的所有数据后,连接应正常关闭。
答案 2 :(得分:0)
感谢您的快速回复。与此同时,我发现了什么问题:
我的应用程序是一个服务器应用程序,创建一个客户端进程,并设置一个TCP套接字用于与该客户端进程通信(使用C命令完成:
snprintf(buf, 1024, "client_process.exe %s %d", szListenHost, iListenPort);
CreateProcess(NULL, buf, NULL, NULL, FALSE, dwCreationFlags, NULL, NULL, &sin, &pin);
有时根据我启动服务器进程的地方,这很好,有时候不行:当我从官方目录启动它时,它工作正常。当我从我的开发环境中启动它时,它无法正常工作。 原因很简单:在我的开发环境中,当前目录中没有“client_process.exe”文件。
我现在已将“client_process.exe”复制到该目录中,并添加了一个额外的检查:
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"); }
}
亲切的问候