引用：JackJiang 发表于 2017-09-25 21:47
你的理解其实也是方案的一种，但一个现实情况是：
在高并发的场景下有些逻辑能放到客户端做的就尽量别放 ...

你好，我想说一下自己的看法。
我觉得重发应该放在服务端而不是客户端。如果重发逻辑在客户端，会有这样两个现象：
1.假如clientB网络不好（偏远山区2G网），那么由于clientB的原因导致clientA需要不断的重试，然而A给其他人发消息都没问题，唯独给B发消息发不过去。
2.很多人用IM(如微信）的时候有这样的习惯，发送一条消息后，就直接把微信切后台或关掉了，如果消息发送到server端成功，但发送到clientB失败了，由于clientA已经关闭，消息就不能重发了，这样也是不好的。

不是很理解，既然tcp已经提供了确认机制，为什么应用层还要再加一个呢？

引用：110766457 发表于 2019-01-22 13:30
你好，我想说一下自己的看法。
我觉得重发应该放在服务端而不是客户端。如果重发逻辑在客户端，会有这样 ...

你说的第1种情况：如果此时B的网络确实差，对于服务端而言，就会判定对方离线，此时走离线消息逻辑就可以了，而A这边会收到服务端的伪应符包——对于A的体验是，消息还是送出了，只是不知道对方是不是实时收到了还是存入离线了而已；

第2种情况：确实存在这样的问题，但这是非常极端的情况下，而且一般的算法，在app挂起时，重传逻辑也挂起了，下次打开时还会重新开始。但，如果app被系统杀掉了就没招了。

但做法没有一个固定的套路，这也是im为什么不好写的原因，因为不标准，一百个人有一百个实现方法。能解决自已的问题就行了，不用太过纠结

引用：hujisha 发表于 2019-03-02 10:25
不是很理解，既然tcp已经提供了确认机制，为什么应用层还要再加一个呢？

你需要读一下这篇文章：《为什么说基于TCP的移动端IM仍然需要心跳保活？》

群主好，请问在A和B都同时在线的时候，又不用做“已读”功能
是否可以简化为这样？

引用：lijingpei2016 发表于 2019-04-10 14:28
群主好，请问在A和B都同时在线的时候，又不用做“已读”功能
是否可以简化为这样？

如果你读过我写的 MobileIMSDK的源码，就可以知道，我认为：应答应该由B来告诉A，而不是由服务器，这样最精简，也最精确，因为收没收到B的应答是最精准的

引用：JackJiang 发表于 2019-04-10 14:55
如果你读过我写的 MobileIMSDK的源码，就可以知道，我认为：应答应该由B来告诉A，而不是由服务器，这样最 ...

B如何告诉A呢？

我想买一份你的源码

请问有关于用TCP还是UDP的分析的文章么？目前初接触IM，还在写玩具玩，个人认为TCP能省不少事=。=

找到了=。=

引用：JackJiang 发表于 2019-04-10 14:55
如果你读过我写的 MobileIMSDK的源码，就可以知道，我认为：应答应该由B来告诉A，而不是由服务器，这样最 ...

关于这一点我不太想得通
我目前认为，在具有离线存储功能的消息系统中，由服务器ack client_a 就足够了。
至于由client_b 做ack更精准，我觉得这一步更像是为 【未读-已读】做服务。
至于群主前面说的，当client_b离线时由服务器替client_b做伪ack，其实还是由服务器做ack罢了

顺便问下，系统消息与客户端消息的处理过程，应该差不多吧

a为什么需要关心b是否收到消息，a只需要保证是否收到server的response就可以了。b是否收到消息由b和server之间的ack保证就可以了。按照你的设计思路，如果server给b下推了a发送的消息，但是b由于网络原因没有收到，那岂不是a要一直重新发送吗？

源码3.0中没有处理粘包的情况吗，我只看到直接一堆发出去了，没有包头吗

引用：yangyang 发表于 2020-09-25 15:17
源码3.0中没有处理粘包的情况吗，我只看到直接一堆发出去了，没有包头吗

你指的源码，具体指的是哪个工程？

请教楼主，如果用tcp的话，Qos机制还有必要吗？

引用：pengion 发表于 2021-02-14 21:06
请教楼主，如果用tcp的话，Qos机制还有必要吗？

应用层的情况很复杂，QoS有必要

要是想要实现消息历史记录，服务端就需要存储消息，是不是就不用这种方式了

引用：某非著名程序 发表于 2021-03-10 19:30
要是想要实现消息历史记录，服务端就需要存储消息，是不是就不用这种方式了

需要

引用：JackJiang 发表于 2021-02-15 16:05
应用层的情况很复杂，QoS有必要

没太理解，有什么帖子能解释吗？tcp已经有了重传和去重的机制，为什么还要Qos。。。

引用：pengion 发表于 2021-03-19 09:11
没太理解，有什么帖子能解释吗？tcp已经有了重传和去重的机制，为什么还要Qos。。。

这里的重传和去重，主要是应用层的逻辑带来的，跟tcp协议栈这一层无关

引用：JackJiang 发表于 2021-03-19 12:19
这里的重传和去重，主要是应用层的逻辑带来的，跟tcp协议栈这一层无关

应用层的逻辑是具体指什么？能详述下或者有什么文章参考吗

引用：pengion 发表于 2021-03-25 20:54
应用层的逻辑是具体指什么？能详述下或者有什么文章参考吗

这篇文章《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》，第4节“4、TCP协议的可靠性之外还会出现消息丢失？”应该能解答你的问题。