求教基于websocket写的im中，心跳该谁发ping（客户端还是服务端？）

IM。 websocket心跳设计。  谁先主动发ping。   客户端发，然后服务端回复pong？然后两边做超时检测？   还是服务端主动发ping，客户端回复pong。   另外是自己应用层自己做心跳，还是直接用ws的ping/pong帧。  各自有啥优缺点

一般来说都是客户端主动一起心跳包（也就是WebSocket里所谓的Ping包）。
对于客户端来说，它自已能知道自已的网络状况，并根据网络情况，决定何时时、以何种策略发起心跳请求，而对于服务端来说，它是瞎子，只能被动等客户端发过来并反馈应答包（也就是Pong包）。

主流的有关心跳和算法和思路都是客户端主动发起，你参考一下：
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《Android P正式版即将到来：后台应用保活、消息推送的真正噩梦》
《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》
《正确理解IM长连接的心跳及重连机制，并动手实现（有完整IM源码）》
《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》

引用：JackJiang 发表于 2022-03-10 18:11
一般来说都是客户端主动一起心跳包（也就是WebSocket里所谓的Ping包）。
对于客户端来说，它自已能知道自 ...

服务端发的我也见过，但好像客户端主动发的多。  有啥优缺点呢

引用：ykpeng 发表于 2022-03-10 18:20
服务端发的我也见过，但好像客户端主动发的多。  有啥优缺点呢

看来你真的看懂我的回答。你只要记住客户端主动发是绝大多数场景下的最佳实践就对了

引用：ykpeng 发表于 2022-03-10 18:20
服务端发的我也见过，但好像客户端主动发的多。  有啥优缺点呢

服务端发更加麻烦. 要开超级多的定时任务, 会增加服务端的压力

一般双方都可以进行pingpong，但通常来说，基于cs也好bs也罢，都是由服务端发起ping 客户端进行pong，服务端发起的ping 如果没回应 比如5次 服务端可以主动断开客户端，相反由client发起ping 的话，如果client异常断开 如停电，非法关机或非法关闭进程 那服务端岂不是一直认为客户端在线。相反 服务端发起 如果没响应 那就可以主动的将服务端的客户句柄抹掉。。这里不清楚你的设计的架构，当然你也可以客户端发起，但是更多的还要在服务端设计，否则就会引起各种问题。

引用：qq010101 发表于 2022-12-21 21:10
一般双方都可以进行pingpong，但通常来说，基于cs也好bs也罢，都是由服务端发起ping 客户端进行pong，服务 ...

你的项目是真的由服务端发起ping，还是只是个理论构想

引用：qq010101 发表于 2022-12-21 21:10
一般双方都可以进行pingpong，但通常来说，基于cs也好bs也罢，都是由服务端发起ping 客户端进行pong，服务 ...

服务端发起的话，对于每个链接是否需要设置独立的心跳发送定时任务呢？还说只用一个统一的定时任务？如果是客户端发起，服务不需要维护大量定时器就可以做到每个链接有独立的心跳间隔，只要记录每次心跳的时间，定时清理超时链接就可以很好得做到关闭无用的链接了，实践起来应该要比服务端发起心跳要简单，逻辑上也更加说得通一点