问题：关于tcp连接是否需要维持心跳？还是用keepalive?
这个问题困扰我好久。tcp连接对端断开后，有时候要好久才能够知道连接已断开，特别是由于中间网络设备的原因或者网线的原因导致的断开。
另外，如果使用的是较慢速的连接，如通过3G、电话拨号后建立的tcp连接，在对端断先后，总是不能及时得知tcp连接断开，有时候甚至要等近一个小时。
请问一下各位在设计基于tcp的应用时有没有遇到这个问题？ 如何解决？用tcp的option (keepalive)?还是其它方法？ 我的看法：用心跳方式在大多数应用场合优于keepalive方式。具体参考《UNIX网络编程卷1》的论述。
主要是KeepAlive有副作用。TCP/IP断开不通知是有意这么设计的，不是缺陷。 我的看法：用心跳方式在大多数应用场合优于keepalive方式。具体参考《UNIX网络编程卷1》的论述。
主要是KeepAlive有副作用。TCP/IP断开不通知是有意这么设计的，不是缺陷。 本帖最后由 laja 于 2011-3-24 09:26 编辑
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15
keepalive感觉也挺好的，起码在大量客户端时开销小 谢谢！
接着来：
1. KeepAlive有副作用在《UNIX网络编程卷1》哪一章有说明？
2. 能否解释一下以下语句？多长时间可以得到断开通知？
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15 winston是对的。
你可以借鉴一下所有系统级的集群软件，都是基于heartbeat. 级的，都是基于heartbeat
=========================
我觉得集群软件是为了立即获得断开通知,这个使用heartbeat是唯一的方式.
如果不是那么实时的场合呢?
关键是keepalive是否可靠? 我担心的是keeplive并不可靠
页:
[1]