默认
发表评论 28
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
[已回复] 求助MobileIMSDK客户端在接收方断网重连情况下有消息服务端会转发失败
A一直给B发消息  然后B断网  A继续给B发  这时候走离线存储   B重连上线  拉取到离线存取的消息  然后继续给B发消息  这时候服务器端转发有部分消息会无法实时送达  

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

标签:MobileIMSDK

QQ图片20200927152324.png (392.34 KB, 下载次数: 4629)

QQ图片20200927152324.png
上一篇:[已回复] 请问MobileIMSDK默认的心跳时间是三秒还是十五秒下一篇:请问 MobileIMSDK-5.0 TCP协议IM,集群有什么好的解决方案?
推荐方案
评论 28
能把你说的这整个过程拍个视频吗,我看看你说的具体是什么样的效果?

或者你把界面的表现,按照你说的顺序,依次截图,让我理解你做是什么样的功能操作,以及对应的界面上是什么表现。

然后我按照你的具体操作来帮你分析情况。
引用:JackJiang 发表于 2020-09-27 15:35
能把你说的这整个过程拍个视频吗,我看看你说的具体是什么样的效果?

或者你把界面的表现,按照你说的顺 ...

[已回复] 求助MobileIMSDK客户端在接收方断网重连情况下有消息服务端会转发失败_QQ图片20200927161128.png [已回复] 求助MobileIMSDK客户端在接收方断网重连情况下有消息服务端会转发失败_QQ截图20200927161220.png

好的,晚点帮你看
你明白你说的了,你的意思是,你的接收端非正常退出,服务端无法及时知道对方已掉线的这个间隔期内(这种情况下,服务端只能在超时到来后才知道对方已掉线),发送的消息,不知道去哪里了是吗?
引用:JackJiang 发表于 2020-09-27 22:47
你明白你说的了,你的意思是,你的接收端非正常退出,服务端无法及时知道对方已掉线的这个间隔期内(这种情 ...

我现在是把这种离线的 和无法送达的消息都存缓存里了  然后用户上线的时候他在拉取  但是现在只能拉取到离线回调时保存的消息       无法送达回调保存的消息需要再一次拉取 才能拉取到  
引用:111111111111111 发表于 2020-09-28 08:54
我现在是把这种离线的 和无法送达的消息都存缓存里了  然后用户上线的时候他在拉取  但是现在只能拉取到 ...

你确切地回答我6楼的问题,是还是不是就好了。这样我就可以准确给你答案了。因为,我担心我想的,跟你想的不是同一个东西。
引用:JackJiang 发表于 2020-09-28 09:49
你确切地回答我6楼的问题,是还是不是就好了。这样我就可以准确给你答案了。因为,我担心我想的,跟你想 ...

是的   这种无法到达的消息  如何处理比较好
引用:111111111111111 发表于 2020-09-28 10:01
是的   这种无法到达的消息  如何处理比较好

im里为了保证消息的送达,其实是个非常复杂的事情。你说的这种情况,是保证消息不丢的一个非常刁钻的维度,没有经验的开发者通常都会搞丢。

我来引导你理解一下这个问题:你现在的疑惑就是,这个超时时间内的消息无法送达,但是它又不走离线,它去哪了,你现在不明白?是不是这样?

你直接回答我的问题就好了。我按你的回答难你合适的答案。
引用:JackJiang 发表于 2020-09-28 10:23
im里为了保证消息的送达,其实是个非常复杂的事情。你说的这种情况,是保证消息不丢的一个非常刁钻的维度 ...

嗯 是的

好的,我来告诉你,这种情况下的消息,该从哪里拿到。

这种情况下,因为客户端的非正常退出,TCP协议对于这种情况是无能为力的,服务端也是无法知道客户端此时的“在线”状态是“脏”的,不准确的。

但MobileIMSDK的QoS消息送达保证机制还有最后一道防线:也就是,无论客户端非正常退出、还是崩溃、或者是服务端线程执行等等过程中发生任何错误,只要对方没有回复ACK应答包,就通通不认为消息“已送达”。

所以:你帖子里描述的极端情况,MobileIMSDK可以通过QoS事件回调,获知哪些消息发送时对方是“在线”但并未真正收到,可以在这个事件通知里对这些消息进行离线存储,下面是RainbowChat产品中的实现,你参考一下:
[已回复] 求助MobileIMSDK客户端在接收方断网重连情况下有消息服务端会转发失败_1.jpg
[已回复] 求助MobileIMSDK客户端在接收方断网重连情况下有消息服务端会转发失败_2.jpg
引用:JackJiang 发表于 2020-09-28 14:28
好的,我来告诉你,这种情况下的消息,该从哪里拿到。

这种情况下,因为客户端的非正常退出,TCP协议 ...

我目前是已经离线存储这些未送达的消息     但是按视频中的操作    这些存进去的消息他不是一个时间上的  可能会出现    我用户上线后 拉取完之后   他又走了未送达的回调 继续存进去    这里就要在拉取一次了
引用:111111111111111 发表于 2020-09-28 15:07
我目前是已经离线存储这些未送达的消息     但是按视频中的操作    这些存进去的消息他不是一个时间上的  ...

我看日志  该用户断网之后有几条消息走了未送达这里没问题     然后该用户上线之后  拉取前面未送达的消息  在这过程中  又有消息未送达了   所以用户就看不到后面未送达的消息
引用:111111111111111 发表于 2020-09-28 15:07
我目前是已经离线存储这些未送达的消息     但是按视频中的操作    这些存进去的消息他不是一个时间上的  ...

你后端的逻辑搞复杂了,只要是对方在线未送达的,立马存库,对方上线后,用http接取离线。就这么点事,千万别搞复杂,什么没上线就先存,逻辑绕太复杂了,im里的逻辑是一定要简化,能简单绝不能搞复杂。因为im从底到上本身就很繁杂,业务层再弄复杂,那就要死人了
引用:JackJiang 发表于 2020-09-28 15:11
你后端的逻辑搞复杂了,只要是对方在线未送达的,立马存库,对方上线后,用http接取离线。就这么点事,千 ...

用户上线后拉取离线消息                 然后又有未送达的消息     这部分消息等用户下次上线在拉取吗   
引用:111111111111111 发表于 2020-09-28 15:33
用户上线后拉取离线消息                 然后又有未送达的消息     这部分消息等用户下次上线在拉取吗   ...

上线后就应该是“在线状态”,以后的消息都应该在线送达才对怎么会还存在未送达的消息呢
引用:JackJiang 发表于 2020-09-28 15:39
上线后就应该是“在线状态”,以后的消息都应该在线送达才对怎么会还存在未送达的消息呢

有没有可能   就是上线前  有部分消息没有走完处理    接收方上线完之后    才保存进去的
引用:111111111111111 发表于 2020-09-28 15:48
有没有可能   就是上线前  有部分消息没有走完处理    接收方上线完之后    才保存进去的

不太可能。

你们把服务端的逻辑做一下减法,去掉你们自已加的复杂内容。离线就是存库,上线就是http接离线。没别的逻辑了。
引用:JackJiang 发表于 2020-09-28 15:53
不太可能。

你们把服务端的逻辑做一下减法,去掉你们自已加的复杂内容。离线就是存库,上线就是http接 ...

我就加了个离线保存的     别的地方都没有加                    看打印出来的日志   在用户上线后    是有部分消息继续走未送达的回调
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部