关于RTM目前支持断线补发吗

网络不稳定断线情况下可以支持补发吗

对于频道消息而言,网络恢复之后,server 会补发之前没收到的消息,频道消息会缓存 30s,如果 30s 内没有重连上,那么消息就会丢失。

点对点消息而言,对于非离线消息,等待时间 1s,如果 1s 内没有收到消息,这条消息会被丢掉,发送端会显示发送失败。

恩,我也有看到文档这块更新说明了,但是我测试好像并没有收到补发啊,我是两个成员加入同一频道,A关闭wifi断网,然后B发送,A重连上在ChannelMessage中没有收到任何消息啊,我使用的1.1.0SDK,是哪里有问题吗

是在 30s 重连上的吗?你更新到 v1.3.0 试试看,如果 v1.3.0 也有问题,请提供双方的 SDK 日志,我们来排查一下。

差不多我断网后就开始重连了, 现在都更新到1.3了啊,我看文档写的1.10就更新了,看发布文档最新是1.2.2啊

我看了下最新是1.2.2,1.3还没有发布吧

嗯 web 端目前最新是 1.2.2。麻烦提供一下日志,我们看下。

im_202006021355.log.zip (9.4 KB)
这个是我刚才测试的,已经升级为1.2.2版本,依然收不到

问一下,你们这个补发是socket在未断线之前的协议补发,还是说咱们服务端实现的一个补发队列,如果是前者那在断线后确实会补发失败,如果是后者那应该会收到未达到消息,咨询下你们是如何知道消息是否到达呢

频道消息当前仅 sender 到 server 之间是有 ack 确认和重传机制;而从 server 到 receiver 之间是单向扩散发送,无 ack,无重传的模式,即下行是不可靠的。

因为你是接收端断网,所以确实是收不到消息的。

上行有ACK,下行无ack, 那如果未连接,我上行发送也是失败的啊,如何要补发也是客户端自行实现吧,那咱们文档说的30秒补发指的是哪块呢

你是怎么判断发送端发送失败的?你给的是发送端的日志吗,对应的时间点是什么?

我给的是接收端的日志,我一直以为补发是接收端断网后会接收到未到达信息,我看如果断网发送回触发发送失败吧,如果要做客户端补发是不可以在这做,您说的上行ACK是哪个回调,我没有看到

不是,补发的意思是,假设发送端在发送消息时断网了,如果发送端用户能在 30s 重连上,那么这条消息还是可以被发出去。如果是接受端断网时,发送端在此时发送消息,那么接收端即使重连上了也是收不到消息的。后续 sdk 应该会优化这一块的逻辑。

不是回调,这里说的就是 sdk 内部的设计机制。

恩,我测试了,本地发送如果失败了也不会补发了,这块是不还是有点问题,咱们也是用websocket做的吧,按理说确实没断开前发送的数据会在重连上发送出去,可能是我用切换网络测试的问题,谢谢你的解答,我就是测试了解下这块,现在看来可能确实达不到预期,等待我这边继续优化

是基于 websocket 的,

这个应该不太正常,我们测下来是会补发的,不清楚你那边的测试流程是怎样的呢?

好的,我们也会反馈给相关同事。