请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 46
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
引用: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为什么不好写的原因,因为不标准,一百个人有一百个实现方法。能解决自已的问题就行了,不用太过纠结
签名: 《马蜂窝旅游网的IM客户端架构演进和实践总结》:http://www.52im.net/thread-2796-1-1.html
引用:hujisha 发表于 2019-03-02 10:25
不是很理解,既然tcp已经提供了确认机制,为什么应用层还要再加一个呢?

你需要读一下这篇文章:《为什么说基于TCP的移动端IM仍然需要心跳保活?
签名: 《马蜂窝旅游网的IM客户端架构演进和实践总结》:http://www.52im.net/thread-2796-1-1.html
群主好,请问在A和B都同时在线的时候,又不用做“已读”功能
是否可以简化为这样?


同时在线发消息逻辑

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

如果你读过我写的 MobileIMSDK的源码,就可以知道,我认为:应答应该由B来告诉A,而不是由服务器,这样最精简,也最精确,因为收没收到B的应答是最精准的
签名: 《马蜂窝旅游网的IM客户端架构演进和实践总结》:http://www.52im.net/thread-2796-1-1.html
引用:JackJiang 发表于 2019-04-10 14:55
如果你读过我写的 MobileIMSDK的源码,就可以知道,我认为:应答应该由B来告诉A,而不是由服务器,这样最 ...

B如何告诉A呢?

我想买一份你的源码
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部