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

A一直给B发消息  然后B断网  A继续给B发  这时候走离线存储   B重连上线  拉取到离线存取的消息  然后继续给B发消息  这时候服务器端转发有部分消息会无法实时送达  

引用：JackJiang 发表于 2020-09-29 22:11
把第3个参数的“-1”改成“3”，再试试

啊哈哈！我们在接收方上线后增加了延迟 2s 拉取离线消息的机制，看来目前这个问题没有再一次出现了。

引用：111111111111111 发表于 2020-09-29 11:47
改成2000之后 还是会有   但是数量没有以前多了

把第3个参数的“-1”改成“3”，再试试

引用：JackJiang 发表于 2020-09-28 23:04
我大致明白你们的意思了。

你们试着改一下服务端的参数，把这个类的源码复制到你们工程（目的是覆盖sdk ...

改成2000之后 还是会有   但是数量没有以前多了  

我大致明白你们的意思了。

你们试着改一下服务端的参数，把这个类的源码复制到你们工程（目的是覆盖sdk的jar中的同名文件）：https://gitee.com/jackjiang/MobileIMSDK/blob/master/sdk_src/Server/MobileIMSDKServer_Open/src/net/x52im/mobileimsdk/server/qos/QoS4SendDaemonS2C.java

修改后的代码内容为：

/*
 * Copyright (C) 2020  即时通讯网(52im.net) & Jack Jiang.
 * The MobileIMSDK v5.x Project. 
 * All rights reserved.
 * 
 * > Github地址：[url]https://github.com/JackJiang2011/MobileIMSDK[/url]
 * > 文档地址：  [url]http://www.52im.net/forum-89-1.html[/url]
 * > 技术社区：  [url]http://www.52im.net/[/url]
 * > 技术交流群：320837163 ([url]http://www.52im.net/topic-qqgroup.html[/url])
 * > 作者公众号：“【即时通讯技术圈】”，欢迎关注！
 * > 联系作者：  [url]http://www.52im.net/thread-2792-1-1.html[/url]
 *  
 * "即时通讯网(52im.net) - 即时通讯开发者社区!" 推荐开源工程。
 * 
 * QoS4SendDaemonS2C.java at 2020-8-22 16:00:59, code by Jack Jiang.
 */
package net.x52im.mobileimsdk.server.qos;

import java.util.ArrayList;

public class QoS4SendDaemonS2C extends QoS4SendDaemonRoot
{
	private static QoS4SendDaemonS2C instance = null;
	
	public static QoS4SendDaemonS2C getInstance()
	{
		if(instance == null)
			instance = new QoS4SendDaemonS2C();
		return instance;
	}
	
	private QoS4SendDaemonS2C()
	{
		super(2000, 0 , -1, true, "-本机QoS");  // 修改了此行！！！！！将原“0”改为了2000现值。
	}
}

用新的代码重新编译，再试。

服务端的代码

我们的问题你那边现在清楚了么？好担心我们说岔了
就是正常消息失败的验证是：发送完等“一段时间”如果没有应答判断为发送失败。
而在这“一段时间”之中如果接收方上线并拉取未读消息，但是服务端还没有到判断失败的时间，这一条消息就不回被接收方拉取。

Android 端代码：

重连成功之后的处理：

-----------------
拉取未读消息的方法

Android 端代码：

重连成功之后的处理：

-----------------
拉取未读消息的方法

楼主的意思是：
1：消息在发出之后**一段时间**没有应答才会提示失败。
2：在这“一段时间”之中，接收方上线并拉取了之前的离线消息，但是因为还在这个“一段时间”之中，所以最新的消息是还没有走到失败回调的。所以：接收方拉取到的离线消息会丢失（没有）这几条，需要再次拉取才会出现。

引用：JackJiang 发表于 2020-09-28 15:53
不太可能。

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

我就加了个离线保存的     别的地方都没有加                    看打印出来的日志   在用户上线后    是有部分消息继续走未送达的回调

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

不太可能。

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

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

有没有可能   就是上线前  有部分消息没有走完处理    接收方上线完之后    才保存进去的

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

上线后就应该是“在线状态”，以后的消息都应该在线送达才对怎么会还存在未送达的消息呢

引用：JackJiang 发表于 2020-09-28 15:11
你后端的逻辑搞复杂了，只要是对方在线未送达的，立马存库，对方上线后，用http接取离线。就这么点事，千 ...

用户上线后拉取离线消息                 然后又有未送达的消息     这部分消息等用户下次上线在拉取吗   

引用：111111111111111 发表于 2020-09-28 15:07
我目前是已经离线存储这些未送达的消息     但是按视频中的操作    这些存进去的消息他不是一个时间上的  ...

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

引用：111111111111111 发表于 2020-09-28 15:07
我目前是已经离线存储这些未送达的消息     但是按视频中的操作    这些存进去的消息他不是一个时间上的  ...

我看日志  该用户断网之后有几条消息走了未送达这里没问题     然后该用户上线之后  拉取前面未送达的消息  在这过程中  又有消息未送达了   所以用户就看不到后面未送达的消息

引用：JackJiang 发表于 2020-09-28 14:28
好的，我来告诉你，这种情况下的消息，该从哪里拿到。

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

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

引用：111111111111111 发表于 2020-09-28 10:34
嗯 是的

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

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

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

所以：你帖子里描述的极端情况，MobileIMSDK可以通过QoS事件回调，获知哪些消息发送时对方是“在线”但并未真正收到，可以在这个事件通知里对这些消息进行离线存储，下面是RainbowChat产品中的实现，你参考一下：

引用：JackJiang 发表于 2020-09-28 10:23
im里为了保证消息的送达，其实是个非常复杂的事情。你说的这种情况，是保证消息不丢的一个非常刁钻的维度 ...

嗯 是的