问题
This question is an extension to this previously asked question:
I implemented the solution given by jxh with following params:
SO_KEEPALIVE = Enabled
TCP_KEEPIDLE = 120 secs
TCP_KEEPINTVL = 75 secs
TCP_KEEPCNT = 1
Then why the server still waits forever for client to respond?
Also I found out on internet that
kill <pid> actually sends SIGTERM to the given process.
So I used ps -o pid,cmd,state command after 'killing' the telnet application.
I saw that the telnet process was still there but with process state = T, i.e. it was in STOPPED state
P.S.: I do not have much knowledge of Linux Signals, please consider that.
回答1:
Since the client processes are still alive, then the TCP stack in the kernel will process the keep-alive packets it receives with an acknowledgement packet back to the sender of the packet. So, even though the connection is indeed idle, the connection will never be closed since the kernel is happily processing the packets.
On a real network, given your parameters, the connection would be closed if the ACK from the client machine ever got lost. On your setup, since the client and server are on the same machine, your network will be essentially lossless.
It is unclear to me how you got your telnet sessions in this state. SIGTERM will not put a process in the stopped state. The process goes into stopped state when receiving SIGSTOP (and usually SIGTSTP, but it seems telnet ignores that one). I suggest that perhaps you sent that signal by mistake, or you suspended the session (with ^]z). When that happened, you should have seen in the window, the one with your telnet session, generate output like:
[1]+ Stopped telnet ...
This is printed by the shell. When the telnet process is stopped, it won't process the SIGTERM until after it is placed in the foreground.
A SIGKILL (done with kill -9 <pid>) will be processed immediately.
回答2:
Because the client hasn't exited yet, being still in STOPPED state, and therefore hasn't closed its connections either.
来源：https://stackoverflow.com/questions/18311222/why-server-waits-for-a-client-after-the-client-application-has-been-put-in-stopp