求助，IM离线消息在什么情况下保存比较合适呢？

请教下：发送消息的时候，消息在什么情况下保存成为离线消息呢？

之前看过网站里的一篇帖子，说是根据用户的在线状态来确定是否保存为离线消息，但是用的在线状态不是很及时呀。

比如说有这样一种场景：client-A给client-B发送一条消息，假设两个客户端现在都是在线的，client-A发送了一条消息为：“hello world”，服务端也收到了该消息，就在服务端收到消息的同时，client-B突然由于一些意外的网络状况断线了，但是服务端此时并不不知道client-B已经断了，服务端还是认为client-B此时是在线的

所以上面这种情况，应该如何处理呢？上面这种情况应该是保存成为离线消息吗？如果保存成为离线消息的话，应该依据啥来保存呢？client-B的在线状态肯定不可靠了

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

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

引用：JackJiang 发表于 2020-09-24 15:57
是的。

那在客户端的超时重传下，数据库存的消息不就会出现重复无效的数据吗？还是说服务端要判断下再保存？

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

是的。

引用：JackJiang 发表于 2020-09-24 15:28
需要两个逻辑：

还是说只要 client-A 发送到服务器的上半场就把消息存下？

引用：JackJiang 发表于 2020-09-24 15:28
需要两个逻辑：

在之前你的那篇六个报文的文章中，如果 client-B 没有回应 ack , 是让客户端 client-A 那边来重传的，如果是 client-A 重传次数上限后，这条消息是存是不存呢

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

需要两个逻辑：

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

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

引用：JackJiang 发表于 2020-09-24 15:10
是的。

大佬，什么时候重传，什么时候视为离线呢？

引用：JackJiang 发表于 2020-09-24 15:10
是的。

好的 感谢大佬解惑

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

是的。

引用：JackJiang 发表于 2020-09-24 14:51
是的，这种情况很复杂，A通过Sever，发消息给B的时：

这么说的话，服务端是不是要有个定时机制，来定时检测下 消息接收方在规定时间内是否回传了ack，如果消息接收方超过了服务端规定时间后还是没有给服务端发送ack，服务端就把该条消息保存成为离线消息

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

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

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

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

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