[已回复] 关于MobileIMSDK重新登录时机的判定疑问

在极端情况下，比如手机切换网络（wifi切换，或切换到4g网络），客户端自动重连但没有抛出重连事件，这时候该如何判断重新登录？
服务端对于那些连接上来，但没有登录的链接，是否需要在一段时间后清理？这会不会很耗费资源？

引用：kezhaoyuan 发表于 2016-05-02 16:17
对于MobieIMSDK的握手流程我不清楚。
从您的回复中，我理解是这样的：
MobieIMSDK的握手成功后（即连接 ...

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

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

引用：JackJiang 发表于 2016-04-29 17:21
我明白你的意思了。

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

对于MobieIMSDK的握手流程我不清楚。
从您的回复中，我理解是这样的：
MobieIMSDK的握手成功后（即连接成功后），但并未认证身份的时候，是不会发送心跳包的。只有认证身份后，才会发送心跳包保活。
是这样吗？

我明白你的意思了。

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

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

总之，由于MobileIMSDK使用的是UDP协议，所以号称“轻量级”不是没有道理的，一切你按最轻爽最简单的思维来理解它就行了，不会有更复杂的机制存在。

引用：JackJiang 发表于 2016-04-21 21:40
我个人建议，移动端的登陆和重连需要跟传统PC端区别理解才行。

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

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

我个人建议，移动端的登陆和重连需要跟传统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啥的机制都是可以的，这拥有最大的灵活性，看你怎么用了），反正回调返回的值决定了你的认证结果。