引用：刘贵林 发表于 2020-09-03 21:57
好的，暂时我们只能发送失败后放入消息延时队列过10秒后再重新发一次

这样处理不够优雅，通信sdk这一层是一定要让事情变的简单，而不是复杂，否则将影响整理体算法复杂度。如果一定想要这样，你可以暂时先什么也不处理，等v5.0版出来，升级sdk就可以了。

引用：JackJiang 发表于 2020-09-03 21:53
目前v4版本的逻辑就是这样的。不过，这个逻辑在MobileIMSDK v5里会变更为你期望的这样，v5版还在整理和和 ...

好的，暂时我们只能发送失败后放入消息延时队列过10秒后再重新发一次

引用：刘贵林 发表于 2020-09-03 21:43
是的，只要消息到了IM服务端就认为是到达，IM服务端若转发失败就走失败的回调存储到服务端作为离线消息

目前v4版本的逻辑就是这样的。不过，这个逻辑在MobileIMSDK v5里会变更为你期望的这样，v5版还在整理和和内部回归测试中，暂时没有正式发布。

引用：JackJiang 发表于 2020-09-03 20:18
你的意思是，希望发送端只要跟服务端连接是好的，消息到服务端，就认为消息被送达是吗

是的，只要消息到了IM服务端就认为是到达，IM服务端若转发失败就走失败的回调存储到服务端作为离线消息

引用：刘贵林 发表于 2020-09-03 19:42
这个有好一点的处理方案吗

你的意思是，希望发送端只要跟服务端连接是好的，消息到服务端，就认为消息被送达是吗

引用：JackJiang 发表于 2020-09-03 19:40
是的，sdk里消息送达保证的逻辑就是：保证不出现消息黑洞（也就是发出去后，对方收到，还是未送达，完全 ...

这个有好一点的处理方案吗

引用：刘贵林 发表于 2020-09-03 19:36
server端基本按照demo的，没做改动

移动端只自己定制发的内容，server端只处理 消息发送成功和失败回调的时候调用服务端接口存储数据

引用：刘贵林 发表于 2020-09-03 19:36
server端基本按照demo的，没做改动

是的，sdk里消息送达保证的逻辑就是：保证不出现消息黑洞（也就是发出去后，对方收到，还是未送达，完全不知道，市面上有些很挫的im就是这样）。

而针对你帖子里提到的这种情况，根本原因是，接收端异常退出，服务端在会话超时检查间隔内，是无法知道接收者的“在线”状态实际是似的，所以只能当在线发送。

但此时，因为有QOS应答机制存在，B端必然是收不到送达ACK应答包，所以B端也能明确知道对方无法收互消息，这条没有实时送达。

总之，以上逻辑保证了消息没丢（不发生消息黑洞情况），而在正经的im产品中，会显示的是一个警告小红色图标（表示未送达，再点一下就可以重发了）。

但由于服务端并不知道对方真离线，所以也并没有走离线回调。

以上逻辑在正经的产品里，是可以说的通的。具体，可以下载RainbowChat产品验证一这个逻辑。

引用：JackJiang 发表于 2020-09-03 19:24
我先问一下，你是在测试demo原版代码在极端网络情况下的表现，还是现在正基于MobileIMSDK写一个im？
你可 ...

server端基本按照demo的，没做改动

我先问一下，你是在测试demo原版代码在极端网络情况下的表现，还是现在正基于MobileIMSDK写一个im？
你可以告诉我实际情况，我就有问题参照点了。