默认
发表评论 10
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
[已回复] 希望MobileIMSDK让所有非网络问题的消息都发出去
场景:A端刚结束进程,B端发送消息给A,B端可以收到消息未送达回执,但是服务端没走onTransBuffer_C2C_RealTimeSendFaild_CallBack方法现实要求:一旦发送失败就走onTransBuffer_C2C_RealTimeSendFaild_CallBack,当成离线处理,客户端还是收到发送到达事件


这样除了网络问题,客户端都认为发送成功


[size=13.0667px]服务端日志:
[size=13.0667px]

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

标签:MobileIMSDK

3.png (131.5 KB, 下载次数: 3035)

3.png

4.png (40.4 KB, 下载次数: 3144)

4.png
上一篇:[已回复] 根据demo部署好MobileIMSDK服务端无法正常登录下一篇:开源轻量级IM框架 MobileIMSDK v5.0 已发布!
推荐方案
评论 10
我先问一下,你是在测试demo原版代码在极端网络情况下的表现,还是现在正基于MobileIMSDK写一个im?
你可以告诉我实际情况,我就有问题参照点了。
引用:JackJiang 发表于 2020-09-03 19:24
我先问一下,你是在测试demo原版代码在极端网络情况下的表现,还是现在正基于MobileIMSDK写一个im?
你可 ...

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

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

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

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

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

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

以上逻辑在正经的产品里,是可以说的通的。具体,可以下载RainbowChat产品验证一这个逻辑。
引用:刘贵林 发表于 2020-09-03 19:36
server端基本按照demo的,没做改动

移动端只自己定制发的内容,server端只处理 消息发送成功和失败回调的时候调用服务端接口存储数据
引用:JackJiang 发表于 2020-09-03 19:40
是的,sdk里消息送达保证的逻辑就是:保证不出现消息黑洞(也就是发出去后,对方收到,还是未送达,完全 ...

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

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

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

目前v4版本的逻辑就是这样的。不过,这个逻辑在MobileIMSDK v5里会变更为你期望的这样,v5版还在整理和和内部回归测试中,暂时没有正式发布。
引用:JackJiang 发表于 2020-09-03 21:53
目前v4版本的逻辑就是这样的。不过,这个逻辑在MobileIMSDK v5里会变更为你期望的这样,v5版还在整理和和 ...

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

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

返回顶部