默认
发表评论 5
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
[已回复] 关于MobileIMSDK重新登录时机的判定疑问
阅读(49356) | 评论(5 收藏1 淘帖1
在极端情况下,比如手机切换网络(wifi切换,或切换到4g网络),客户端自动重连但没有抛出重连事件,这时候该如何判断重新登录?
服务端对于那些连接上来,但没有登录的链接,是否需要在一段时间后清理?这会不会很耗费资源?

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

标签:MobileIMSDK
上一篇:[已回复] MobileIMSDK实现讨论组或者群聊的思路如何实现?下一篇:MobileIMSDK的Android Demo中初始化报空指针问题!

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

推荐方案
评论 5
我个人建议,移动端的登陆和重连需要跟传统PC端区别理解才行。

传统PC端,因为网络非常稳定,掉线情况很小,那么掉线时,重新登陆这合情合理。这里的重新登陆,相当于重新开始一次完整的连接、认证等一整套流程。

移动端时代因为无线网络的稳定性问题,是远不及传统pc网络,极端情况下,频繁的掉线和重连都是有可能,比如你一路拿着手机,从公司出门到从电梯、到走到某个转角处等等,一路的无线信号波动太大,频繁的掉线和重连如果也像pc端一样,每次都来一个完整的连接、认证等整套流程的话,则体验就太差了。

MobileIMSDK为了解决上面的问题,基本上只有首次从app的登陆界面,或重新启动时才进行一次“登陆”,登陆成功,则进入正常的即时通讯算法,这之后的掉线等情况下,只理解为“重连”,而非“重登陆”。也就是说,个人建议,只在app启动时进行“1次”完整的登陆认证,且这个认证最好在MobileIMSDK框架之外的业务上去实现(比如用一个传统的http认证请求流程,这样就简单多了,实现起来门槛也很低,不需要把这层复杂性加到即时通讯里),而一旦进入MobileIMSDK的即时通讯流程,则无条件认为这是已被合法认证后的动作,那么接下来的一系列流程里的掉线得连等,都是mobileimsdk的底层算法的事,对上层而言只需无条件收发消息,成功会有回调,失败也会有回调,从而屏蔽网络及即时通讯的算法复杂性,将api调用极致简化。

当然,上面所说的,需要解决的问题就是通信安全性问题,这也就回到了最精典的数据安全问题了,可以看看这个链接:http://www.52im.net/thread-219-1-1.html。需要解决的安全性问题跟所有主流IM所面临的着呢题是一样的,无非就是要解决:截获、篡改、伪造这样的情况,看看相关安全文章,都能找到解决方案。

最后,MobileIMSDK的服务端回调里,那两个登陆、认证回调,也是完全可以实现传统PC上的掉线即进行完整重登陆的过程,关键就看你回调方法里怎么实现了(比如你让它掉线后查询用户信息、密码,或者你自已加了一层token啥的机制都是可以的,这拥有最大的灵活性,看你怎么用了),反正回调返回的值决定了你的认证结果。
引用:JackJiang 发表于 2016-04-21 21:40
我个人建议,移动端的登陆和重连需要跟传统PC端区别理解才行。

传统PC端,因为网络非常稳定,掉线情况很 ...

您的回复跟我想问的有些偏差。
我这里提到的所谓“登录”,不是指校验账号密码等完整认证流程,而是指在服务端登记身份,即告诉服务端我是谁,就是建立了新的socket后,让服务器知道这条socket对应的是哪个用户。
这里涉及到用户与socket的映射表,即服务器端知道哪个socket对应哪个用户,发送消息时,按用户名来发送,而不是按socket编号来发送。
所以,在socket断开后,客户端重新建立新的socket,还要进行一次“登录”。
在这种情况下,基本上就是socket建立成功后,调用一次“登录”来注册身份。但我想知道,极端情况下,有无可能重建了socket,但无事件响应,导致没有注册身份。那么对于服务端来说,这个socket就是一个无身份的链接。
因为我对底层socket重连不了解,所以有此疑问。
签名: 该会员没有填写今日想说内容.
我明白你的意思了。

可以肯定的是,MobieIMSDK使用的是UDP协议,而UDP协议是无连接的,也就是不像TCP协议这样时刻需要占用信道才能保证后绪数据的畅通,这一点你可以放心了。

但是为何MobileIMSDK的算法保有“会话”这种机制呢?因为MobileIMSDK的服务端底层使用的是MINA,而MINA为了简化网络编程(这也是MINA存在的最大意义),在应用层自已实现了个简单的类似于HTTP服务端应用的Session机制,目的也仅是为了简化开发和理解而已,也并不真正存在连接或其它过多的资源占用。而实际上,MobileIMSDK中,最坏的情况下,服务端即使创建了个未经认证的会话,也会因为无法完成接下来的网络心跳保活机制,而会使得服务端自动给于超时并释放这个“会话”所占用的极微小资源。

总之,由于MobileIMSDK使用的是UDP协议,所以号称“轻量级”不是没有道理的,一切你按最轻爽最简单的思维来理解它就行了,不会有更复杂的机制存在。
引用:JackJiang 发表于 2016-04-29 17:21
我明白你的意思了。

可以肯定的是,MobieIMSDK使用的是UDP协议,而UDP协议是无连接的,也就是不像TCP协 ...

对于MobieIMSDK的握手流程我不清楚。
从您的回复中,我理解是这样的:
MobieIMSDK的握手成功后(即连接成功后),但并未认证身份的时候,是不会发送心跳包的。只有认证身份后,才会发送心跳包保活。
是这样吗?
签名: 该会员没有填写今日想说内容.
引用:kezhaoyuan 发表于 2016-05-02 16:17
对于MobieIMSDK的握手流程我不清楚。
从您的回复中,我理解是这样的:
MobieIMSDK的握手成功后(即连接 ...

MobileIMSDK里,只要客户端没有成功被认证,它发送的任何消息,服务端的返回都会是:RESPONSE_FOR_UNLOGIN

当然,实际部署的时候,真正专业的应用,前置硬件防火墙是必须的(高频的非法UDP请求很容易被探测出来并会被黑洞吞没)。为了防止可能存在的恶意攻击,你也可以设置你的服务端逻辑,比如连续多少次非法登陆的请求直接给忽略等(因为实际应用中,IM应用的所有请求几乎都是人发出的,要想侦测出非法的行为,并不困难)。
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部