如何通过ACE检测客户端已经断线？？急！！！

ligeqq

有些操作系统的TCP/IP协议栈似乎会帮你检测（他也用的是心跳），比如windows，但是要检测出来可能需要比较长的一段时间

http://www.china-pub.com/24236
这本书就有介绍

不过比较好的办法还是自己用心跳

winston

KEEP-ALIVE选项是吧？
那个靠不住，实践中几乎无法操作，因为需要2个小时左右的时间才查到。
看TCP协议详解

rainfish

设置keepalive参数就可以了，
对方网络非正常断开检测方法
http://blog.csdn.net/bat603/archive/2008/06/23/2577792.aspx

winston

用这个参数是有弊端的。参考如下：

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.

gujiwubian

:'( 还是没解决啊，心跳包倒是用了，但是还是有缺陷啊。毕竟心跳包需要花费时间的，如果客户端在这段时间内重新启动的话，问题就出现了。。。

gujiwubian

其他各位大哥大姐说的办法。。。。。。不会，而且很多东西都是成熟的。不好改啊，郁闷郁闷郁闷

winston

实时的确认TCP的对端异常掉线（网络原因，没有结束等消息）是不可能的，参见TCP协议详解和相关的文档。
    如果你需要这种“伪实时”，那么你就需要增加检测机制，这会大大加大系统的负担。但是，根据我的经验，极少有需求不能通过“绕开”或者折中的办法去实现。
    如果你一定要这样，那是没办法的事情。只能说明你们做需求和系统设计的人水平太差了。