1、服务器不能收到客户端的心跳包
不知这来个心跳包传输模式是广播源还是点到点呢
也许是交换机工作模式不匹配你的应用,二级交换可直接广播,三级交换会过滤广播的心跳包.需要三级交换配置下转发广播
检查几点,心跳包发包模式,网络互通,程序设置,交换机工作模式
2、易语言 关于服务端检查客户端是否在线的心跳包问题
在客户端添抄加一个线程袭，用来发送在线的心跳包（此包生成的为时间戳，加密），服务器收到后，自动更新当前在线用户的在线时间
服务器添加一个线种，定时循环检测用户的时间戳，如果大于或小于设定时间（一般在30秒至1分钟）即判断为掉线并做掉线处理；
客户端防故意断网，如果发送信息失败，即断网
3、主从服务器心跳线为什么不能设置公网地址
既然有静态IP，那在那个机器上安装一个FTP服务器软件就可以了，推荐Sevr-U。
你可以到网内上去搜一下容，软件和教程都有很多。
（XP专业版自带的IIS也可以设置FTP服务器）
设置完成后，其他的电脑访问该服务器的FTP地址即可，当然，你可以在服务器上预设需要密码登录的账户。
4、activemq 如何心跳感知接收方与服务器断开
可以添加一个Activemq的消息传输监听，实现 Activemq的TransportListener接口。该接口是有onCommand（）内，onException（）， transportResumed () 等监容听方法。
5、为什么在服务端设计当中需要考虑心跳
的检测，清除死连接，即使在没有数据来往的时候，TCP也就可以（在启动TCP这个功能的前提下）自动发包检测是否连接正常，这个不需要我们处理。
服务端设计心跳包的目的：
探知对端应用是否存活，服务端客户端都可以发心跳包，一般都是客户端发送心跳包，服务端用于判断客户端是否在线，从而对服务端内存缓存数据进行清理（玩家下线等）；问题在于，通过TCP四次握手断开的设定，我们也是可以通过Socket的read方法来判断TCP连接是否断开，从而做出相应的清理内存动作，那么为什么我们还需要使用客户端发送心跳包来判断呢？
第一种判断客户端是否在线策略:
直接监控TCP传输协议的返回值，通过返回值处理应用层的存活判断
比如在C++当中
使用poll的IO复用方法时：
if(fds[i].revents & POLLERR)
if(fds[i].events & POLLDHUP)
通过上述判断可以探知TCP连接的正确性从而在服务器也关闭对应的连接
6、socket心跳检测服务端怎么处理
心跳也是数来据通信中的一种源数据，特殊点在于定时发送，形似心跳而得名。 一般来说，当客户端连接到服务端之后，为了确保了解到连接的状态真实性，或者为了防止某些网络在长时间没有数据传输时自动断开，服务端会定时发送一条数据
7、惠普服务器心跳图标红色
这类专业技术问题可能比较适合去“惠普-惠聚宝”上面咨询，上面有惠普服务器工程师答疑，非惠普服务器也能提供帮助。
8、DL580G7心跳灯变红
您好，感复谢您选择惠普产品制。
很抱歉，百度知道企业平台暂时没有HP服务器产品相应的技术支持。关于服务器产品问题，建议您可以直接拨打支持热线800-810-2058（不支持手机拨打，请使用固话或小灵通拨打）或400-610-2058（可手机拨打）进行咨询。
希望以上回复能够对您有所帮助。
9、从微信谈起，如何优化互联网APP心跳机制
摘要: 微信的信令风暴将人们的目光导向心跳机制，那么心跳机制是怎么回事？又为什么会给移动通信网络带来信令风暴呢？ 孙宇彤，空中接口学园站长 微信的信令风暴将人们的目光导向心跳机制，那么心跳机制是怎么回事呢？ 最早的心跳机制用于服务器的安全备份机制，是为了防止服务器死...
微信的信令风暴将人们的目光导向心跳机制，那么心跳机制是怎么回事？又为什么会给移动通信网络带来信令风暴呢？
孙宇彤，空中接口学园站长
微信的信令风暴将人们的目光导向心跳机制，那么心跳机制是怎么回事呢？
最早的心跳机制用于服务器的安全备份机制，是为了防止服务器死机，而在服务器之间采用专用的端口和线路，周期性传送简短的信息，心跳就是形象的比喻。一旦收不到对方的心跳信息，服务器可以接管对方的业务，避免业务的停滞。为了业务的顺畅进行，服务器发送的心跳信息可以非常频密。
这种机制被手机上的互联网应用所借用，无论是Android的原生应用，还是QQ、微博和微信，都采用了这种心跳机制，也就是终端定时向应用服务器发送简短的信息。但是与服务器之间的心跳机制相比，还是有一些差别：
1. 心跳信息是单方向的，只有终端发到应用服务器；
2. 心跳信息的周期比较长，比如旧版QQ的心跳周期为30s，新版QQ为180s，微信为300s，Google原生应用为1680s左右。
另外，互联网应用的心跳包除了宣告终端在线外，还有一项重要的任务，就是提供终端的即时地址，方便应用服务器的寻址。
有了互联网应用的心跳机制，应用服务器可以及时下发(Push)用户相关的信息，比如微信中的短消息、图片或者语音等。
心跳包也会带来很多副作用，比如终端更为费电，还可能给移动通信网络带来信令风暴。
看起来很完美的心跳机制，为什么会给移动通信网络带来信令风暴呢？
原来，移动通信网络中由于用户众多、资源稀缺，每个用户都是动态占用资源，比如IP地址以及无线信道。每次发送心跳包，都需要移动通信网络为用户分配资源，分配的过程体现在信令的发送和接收上。一次心跳包的发送过程，牵涉的信令多达几十条。
随着互联网APP的普及，大量的终端周期性地发送心跳包，效果类似于IP网络中的DDOS，必然对移动通信网络设备带来冲击，造成拥塞等情况，这种现象就是信令风暴。信令风暴不仅中国移动的GPRS网络存在，中国联通的WCDMA网络、中国电信的CDMA网络都存在。由于中国移动用户数量庞大，因此信令风暴的影响更显著而已，简而言之，就是50步与100步的差别。
互联网APP的心跳机制对移动网络的冲击很大，那么有什么方法可以缓解乃至解决这个问题呢？
从互联网APP的角度看，应该区分是移动网络接入还是WLAN接入，智能调整心跳包的发送频率。在移动网络接入时，降低心跳包的发送频率，这样虽然服务器推送的信息会有一些延迟，但是终端更省电，移动网络更稳健。比如旧版QQ的心跳周期为30s，新版QQ为180s，微信为300s，已经呈现出逐步延长的趋势，还可以再调整，直至接近Google原生应用的1680s左右。
目前，互联网APP心跳包的发送频率由APP一手包办，这是不合理的，应该开放给用户进行设置，允许用户在省电和及时等多个场景间切换。
现在每个人的手机上都装有多个互联网APP，比如QQ、微信、微博和淘宝等，如果每个APP都发送心跳包，心跳包的发送频率将大幅增加。像微信、QQ 等APP，可以考虑联合发送心跳包，这样可以减少不少心跳包。另外如果从操作系统的层面统一心跳包，效果会更好。苹果的IOS已经做了一个很好的尝试，建立了一个位置寄存器APNS，将所有的APP联合起来，统一发送心跳。Android系统其实也可以如法炮制，据称小米手机有意这样做，像阿里OS也应该可以做。运营商自己开发的OS更加应该是这方面的表率。
终端侧的这些做法，将能有效减少心跳包的发送，从而缓解信令风暴。
从网络侧的角度，如果终端发送心跳包是一个既成事实的话，及时进行设备扩容就是势在必行的了。目前看，基站控制器以及核心网的设备受信令风暴的影响大，需要优先扩容。当然，运营商有苦衷，认为是在帮APP打工。但是，运营商也必须明白顺势而为的重要性，与其被动接招，不如早作打算。
什么打算呢？就是宣传从移动网络的角度看，心跳包并不是必须的。利用短消息与APP深度整合，不用心跳包也可以方便地实现APP消息的推送，又节省终端的电力，又避免对移动网络的冲击，两全其美，何乐不为呢？
这样釜底抽薪后，心跳机制对移动网络的冲击将是可以控制的了。
参考：互联网的那点事