求教关于IM消息送达可靠性（QoS应答机制）的实现方案

论坛里关于QoS 保活心跳的帖子也都研究了一遍，还有就是其他人的提问和群主的回复。

群主给的一个方案是由客户端决定超时和重传，还有一个帖子就是讲可靠的确认送达需要六个包，但是六个包每个包都有丢失的可能，这样处理起来感觉太复杂了。

如果超时重传只让客户端做，每次发一条消息然后这个消息放入一个待确认队列里，一定时间没有收到对方发来的确认包就进行一次重传，采用10s 30s 50s失败重试进行重传，都失败了客户端显示发送失败，这样客户端再加一个去重操作就好了，不知道这样的方案在实际应用中如何，对于发六个包确认一个信息的送达感觉处理起来服务端和客户端压力都很大，不知道我的理解有没有错误，感谢各位解答。

引用：leirenbaobao 发表于 2022-10-29 00:05
Jack前辈 IMSDK用了四个包。A->S S->B B->S S->A 这个有文章介绍吗？

准确地说是 A->S S->A  S->B B->S
原理就是这样，没别的好介绍的

引用：leirenbaobao 发表于 2022-10-29 00:05
Jack前辈 IMSDK用了四个包。A->S S->B B->S S->A 这个有文章介绍吗？

[typeu=-1]收到了客户端123456发给客户端111的消息：str=222 | (ServerEventListenerImpl^onTransferMessage4C2C:196)
[DEBUG] - [23:47:55.260][IMCORE-tcp<C2C>]【QoS_伪应答_C2S】向123456发送63DD81D2-5259-4636-A87A-98649A86CC9B的应答包成功,from=111. | (GlobalSendHelper$2$1^update:226)
[INFO] - [23:47:55.260][IMCORE-tcp]<< 收到客户端{uid:111}/127.0.0.1:58724的ACK应答包发送请求. | (ServerCoreHandler^messageReceived:192)
[DEBUG] - [23:47:55.261][IMCORE-本机QoS！]【QoS机制_S2C】收到接收者111回过来的指纹为63DD81D2-5259-4636-A87A-98649A86CC9B的应答包. | (LogicProcessor^processACK:140)
[DEBUG] - [23:47:55.261]【DEBUG_QoS_S2C事件】收到对方已收到消息事件的通知，fp=63DD81D2-5259-4636-A87A-98649A86CC9B | (MessageQoSEventS2CListnerImpl^messagesBeReceived:84)
[WARN] - [23:47:55.262]【IMCORE-本机QoS】【QoS发送方】指纹为63DD81D2-5259-4636-A87A-98649A86CC9B的消息已成功从发送质量保证队列中移除(可能是收到接收方的应答也可能是达到了重传的次数上限)，重试次数=0 | (QoS4SendDaemonRoot^remove:451)

这个是终端打印的日志 对应的分别是ABS中的哪次呀 看得有点晕。

引用：JackJiang 发表于 2016-10-28 09:17
这个问题之前在群里讨论过，这也是我为什么一直懒的在群里讨论技术问题的原因，因为群里讨论只能局部少数人 ...

Jack前辈 IMSDK用了四个包。A->S S->B B->S S->A 这个有文章介绍吗？

说的很好 受益匪浅

说的非常好，收益匪浅！

谢谢。学习到了，非常感谢

引用：JackJiang 发表于 2016-10-28 09:17
这个问题之前在群里讨论过，这也是我为什么一直懒的在群里讨论技术问题的原因，因为群里讨论只能局部少数人 ...

谢谢!感觉思路清晰明了很多

引用：JackJiang 发表于 2016-10-28 09:17
这个问题之前在群里讨论过，这也是我为什么一直懒的在群里讨论技术问题的原因，因为群里讨论只能局部少数人 ...

茅塞顿开，顶群主。。。。。。。

引用：JackJiang 发表于 2016-10-28 09:17
这个问题之前在群里讨论过，这也是我为什么一直懒的在群里讨论技术问题的原因，因为群里讨论只能局部少数人 ...

说的很详细，学习了

这个问题之前在群里讨论过，这也是我为什么一直懒的在群里讨论技术问题的原因，因为群里讨论只能局部少数人能看到。回到正题。

● IM消息送达保证机制实现的前提就是需要对方反馈消息应答ACK包。那么可以不需要应答吗？
● 答案是——不可能：不管是TCP还是UDP理论上都需要应答，因为真正生产环境下，消息的处理并不是一台机器或一个IM实例内的事，它的中转流程可能包括消息队列、转发缓存、离线处理等等，为了高性能，很多环境都是异常实现，即使是TCP传输也不可能同步取得发送结果，所以应答是必然。

主流的移动端IM都有这个机制，逃不掉，不知道有人用过网易的易信没有，易信就更明显，因为它的应答机制里在UI上的表现就是可以显示对方是什么时间读的消息。不信可以去下载一个试试。

● 既然需要发送应答包的话，就肯定得产生额外消耗，在用户量大的时候，消耗体现在：IM服务端带宽、IM服务端计算资源上。有办法减小消耗吗？
● 答案是——肯定有：有些人说实现一个消息送达保证机制，一共需要6个包，有些人说是4个包，当然是能越少越好，具体能几个这要依赖于具体的算法实现。举个例子：MobileIMSDK 中的送保证算法逻辑基本都是在客户端实现（这样既可以减轻服务端的复杂度、也能减低负载、也利于以后的性能优化），MobileIMSDK中使用了4个包：A->S S->B B->S S->A（准确地说是两个包的两次转发，一个是IM消息包一个是IM应答包）。

● 4个包还有办法降低吗？
● 答案是有办法——可以合并应答：如果单独从IM的技术实现细节来看，一送一答，这2个来回共4次（或说4个包的转发），是少不了的。没错，对于每一个包的应答来说是少不了的，但应答包并不一定要每个IM消息包对应一个应答包，我们可以改进IM客户端算法，使其在某一段时间内对应答进行合并（比如100条消息共用同一个应答包（只是这个应答包里包含的应答id是多个而非之前的一个），对于很多IM消息包而言，这应答开销就差不多省下来了，对它而言总共就只用了2个包），这样消息收发峰值时应答包就能降下来，进而降低网络和服务器资源压力。

要睡觉了，明天回复你