是的，这种情况很复杂，A通过Sever，发消息给B的时：

• 1）B突然崩溃；
• 2）B的网络链接中，某个环节的路由器网络被拨；
• 等等...
  

都有可能导致服务端对B的在线状态判断不准确。

最好的办法，是要有ACK应答机制，也就是发给B的消息不管发生什么情况，只要能收到B的ACK消息应答，才算对方已收到，否则表示对方不能实时收到，那就应该存离线。这样可以保证消息不丢。

我觉得你们应该去读一读MobileIMSDK的代码：，MobileIMSDK已经完整实现了这些算法逻辑。

引用：wzyl 发表于 2020-09-24 15:00
这么说的话，服务端是不是要有个定时机制，来定时检测下 消息接收方在规定时间内是否回传了ack，如果消息 ...

是的。

引用：Sfa 发表于 2020-09-24 15:21
大佬，什么时候重传，什么时候视为离线呢？

需要两个逻辑：

• 1）ACK包应答超时机制；
• 2）消息重传机制。
  

当到达ACK应答包的超时后，就重传，重传次数上限达到后，就可以认定这是无法实时送达的，马上存库。

引用：Sfa 发表于 2020-09-24 15:52
还是说只要 client-A 发送到服务器的上半场就把消息存下？

是的。

引用：Sfa 发表于 2020-09-24 16:17
那在客户端的超时重传下，数据库存的消息不就会出现重复无效的数据吗？还是说服务端要判断下再保存？

服务端QoS机制本身在一段时间内，会保存收到的消息指纹码（也就是消息id），如果重复收到某条消息，QoS机制这一层就会过滤掉，不会传达到应用层。