SO_KEEPALIVE Socket OptionWhen the keep-alive option is set for a TCP socket and no data has been exchanged across the socket in either direction for two hours, TCP automatically sends a keep-alive probe to the peer. This probe is a TCP segment to which the peer must respond. One of three scenarios results:
The peer responds with the expected ACK. The application is not notified (since everything is okay). TCP will send another probe following another two hours of inactivity.
The peer responds with an RST, which tells the local TCP that the peer host has crashed and rebooted. The socket's pending error is set to ECONNRESET and the socket is closed.
There is no response from the peer to the keep-alive probe. Berkeley-derived TCPs send 8 additional probes, 75 seconds apart, trying to elicit a response. TCP will give up if there is no response within 11 minutes and 15 seconds after sending the first probe.
HP-UX 11 treats the keep-alive probes in the same way as it would treat data, sending the second probe after a retransmission timeout and doubling the timeout for each packet until the configured maximum interval, with a default of 10 minutes.
If there is no response at all to TCP's keep-alive probes, the socket's pending error is set to ETIMEDOUT and the socket is closed. But if the socket receives an ICMP error in response to one of the keep-alive probes, the corresponding error (Figures A.15 and A.16) is returned instead (and the socket is still closed). A common ICMP error in this scenario is "host unreachable," indicating that the peer host is unreachable, in which case, the pending error is set to EHOSTUNREACH. This can occur either because of a network failure or because the remote host has crashed and the last-hop router has detected the crash.
Chapter 23 of TCPv1 and pp. 828–831 of TCPv2 contain additional details on the keep-alive option.
Undoubtedly the most common question regarding this option is whether the timing parameters can be modified (usually to reduce the two-hour period of inactivity to some shorter value). Appendix E of TCPv1 discusses how to change these timing parameters for various kernels, but be aware that most kernels maintain these parameters on a per-kernel basis, not on a per-socket basis, so changing the inactivity period from 2 hours to 15 minutes, for example, will affect all sockets on the host that enable this option. However, such questions usually result from a misunderstanding of the purpose of this option.
最新回复
目前客户端有 close()函数调用...服务器端可以接收到客户端断开的消息...
但是...如果客户端非正常退出的话...服务器就没办法挨了...
在异常断开的时候，要有判断的办法。
http://www.china-pub.com/24236
这本书就有介绍
不过比较好的办法还是自己用心跳
那个靠不住，实践中几乎无法操作，因为需要2个小时左右的时间才查到。
看TCP协议详解
对方网络非正常断开检测方法
http://blog.csdn.net/bat603/archive/2008/06/23/2577792.aspx
QUOTE:
如果你需要这种“伪实时”，那么你就需要增加检测机制，这会大大加大系统的负担。但是，根据我的经验，极少有需求不能通过“绕开”或者折中的办法去实现。
如果你一定要这样，那是没办法的事情。只能说明你们做需求和系统设计的人水平太差了。