为什么服务器在客户端应用程序处于STOPPED状态后等待客户端?

时间:2013-08-19 10:09:28

标签: c sockets client-server recv suse

此问题是对this previously asked question的扩展

我使用以下参数实现了solution given by jxh

SO_KEEPALIVE = Enabled  
TCP_KEEPIDLE = 120 secs  
TCP_KEEPINTVL = 75 secs  
TCP_KEEPCNT = 1

那为什么服务器仍然等待客户端响应?

我也在网上发现了

kill <pid>实际上将SIGTERM发送到给定进程。

所以我在“杀死”telnet应用程序后使用了ps -o pid,cmd,state命令。

我看到telnet进程仍在那里,但是process state = T,即它处于 STOPPED 状态

P.S。:我对Linux信号知之甚少,请考虑一下。

2 个答案:

答案 0 :(得分:2)

因为客户端尚未退出,仍处于STOPPED状态,因此也未关闭其连接。

答案 1 :(得分:1)

由于客户端进程仍处于活动状态,因此内核中的TCP堆栈会将其收到的保持活动数据包与确认数据包一起处理回数据包的发送方。因此,即使连接确实处于空闲状态,连接也永远不会被关闭,因为内核正在愉快地处理数据包。

在真实网络上,根据您的参数,如果来自客户端计算机的ACK丢失,则将关闭连接。在您的设置中,由于客户端和服务器位于同一台计算机上,因此您的网络基本上是无损的。

我不清楚你是如何在这个州举办telnet次会议的。 SIGTERM不会将进程置于停止状态。在收到SIGSTOP(通常为SIGTSTP时,该过程会进入停止状态,但似乎telnet忽略了该状态。我建议您可能错误地发送了该信号,或者您暂停了会话(使用^]z)。当发生这种情况时,您应该在窗口中看到具有您的telnet会话的那个,生成如下输出:

[1]+  Stopped                 telnet ...

这是由shell打印的。当telnet进程停止时,它将不会处理SIGTERM,直到它被置于前台。

SIGKILL(已完成kill -9 <pid>)将立即处理。