模型总结很好

学习了

引用：kezhaoyuan 发表于 2016-05-11 11:17
你说的跟微信的设计是一致的，把群消息当个人消息处理。
而2个问题我在实际中确实遇到了。
第1个还好解 ...

我觉着这篇文章可以解决你的问题http://www.52im.net/thread-1616-1-1.html。消息存一份就够了。
但是四年前的评论。。。。

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

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

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

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

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

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

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

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

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

需要

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

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

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

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

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

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

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

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

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

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

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

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

找到了=。=

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

B如何告诉A呢？

我想买一份你的源码

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

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

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