默认
发表评论 4
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
[已解决] MobileIMSDK中的心跳发起顺序和送达保证机制
阅读(74901) | 评论(4 收藏1 淘帖1
IM是不是有两种心跳  QoS心跳和keep alive心跳?它们的发起方向顺序是什么?QoS心跳是接收文件的一方应答给发送方,然后发送方再应答接收方,模拟三次握手吗?
Keepalive心跳是客户端向服务器端主动发送,然后服务器再应答客户端,模拟三次握手?

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

标签:MobileIMSDK
上一篇:[已解决] 将demo里的jar替换成源码 打包成apk 登陆后频繁掉线下一篇:[已回复] MobileIMSDK的android版心跳实现是基于异步任务的么

本帖已收录至以下技术专辑

推荐方案
评论 4
你说的是MobileIMSDK吗?
让Jack Jiang来回答吧,他最清楚了。
@JackJiang 呼叫jack
签名: 国庆长假还没有缓过来,请让我静一静,产品狗死远点...
你对心跳的理解可能有点混淆,我来给你解释一下。

1关于Keep Alive心跳


通常来说,IM里的心跳指的是为了TCP或UDP通讯的socket保活而进行的定时向服务端发送keep alive包的机制。

一般来说Keep Alive心跳的作用至少有两个:
1)解决UDP或TCP的端口老化问题(UDP的端口老化时间更短);
2)告诉服务器我还活着(极端情况下,当客户端因程序崩溃等情况而非常退出时,心跳就显得特别重要,尤其在使用UDP这样的“无连接”协议的情况下)。

你上面的理解有关3次握手的概念,这是错误的,心跳机制跟这完全没关系。

2关于QOS


我们讲讲应答机制:
主流的IM(不管是IM云还是像微信这样的产品),都会这个消息应答机制(易信就特别明显,你甚至可以看到对方读消息的时间,也同样是用的应答机制),且无论是UDP协议还是TCP协议。应答机制通常是在消息接收者收到消息的同时,马上发送应答包,发送方只需根据这个应答包来决定对方是否真的是否“收到”消息,这就让丢包(当然丢包的情况有很多种可能,UDP协议自身的特殊性只是其中一种)的判定变的简单。

再来讲讲重传机制:
这个重传机制,跟你说的心跳是差不多的,但是用“心跳”可能容易跟Keep alive机制混淆,所以叫定时线程,可能更准确。它的工作原理是,定期检查已发送队列,当包的生存期已过,就表示这个包从未收到应答包,也就认为着它没有被接收方“收到”,那么自动触发重传机制。

当然,应答和重传机制在MobileIMSDK或者其它IM框架里,实际的实现都比我上面描述的要复杂和强大,我只是为了向你简单地描述原理而已。

以上大概就是这样,我以后会把流程图整理出来。希望能解决你的疑问。
引用:JackJiang 发表于 2016-03-07 14:38
你对心跳的理解可能有点混淆,我来给你解释一下。

学习了,谢谢 jack
点赞
签名: now start 。。。
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部