[已回复] 求教同一账号、不同设备、同时登陆强制下线的优化方法

安卓和IOS存在：同一账号，在多台设备同时登陆的问题，想要改成同一账号只能同时在唯一一台设备上登陆，其他设备强制下线？

这个需求，可以在MobileIMSDK这一层来优化，方法就是在第二个设备上登陆时，服务端发现该账号的会话已存在时，就先踢出之前的会话（先发一个踢出指令，后断开会话），然后再继续正常流程。

这里面有一个难点，就是因为是udp协议，所以最坏的情况下，万一踢出前一个账号时，踢出指令丢了，那就有点麻烦。这个可以建议加一个时间戳，当前一个会话没有收到被踢指令，尝试重连时，带上这个时间戳，服务端比对出这个时间戳比第2个设备上的时间戳早，就意味着这是个已被废弃的会话，再重发给他被踢指令即可。

以上大致的思路就是这样，仅供参考。这个优化可以直接在mobileimsdk的demo里优化好，测试没问题后打jar使用即可，这样方便测试。

重连的时候带上时间戳，确实能解决这个问题，下一个版本里面能不能带上时间戳，我怕我去改源码，反而改烂了，，因为我现在重连的代码在哪儿实现的，都不知道，，，，

会不会有这种情况：
A设备已登录
B设备请求登录
服务端向A设备发送下线指令
A网络很烂，没有收到指令，也没有在预期时间内向服务端送达重连请求
B设备登录成功
此时A设备带着时间戳向服务端发送重连请求
此时A的时间戳晚于B，所以A又成功重连了

引用：dahai2070 发表于 2019-06-17 11:32
重连的时候带上时间戳，确实能解决这个问题，下一个版本里面能不能带上时间戳，我怕我去改源码，反而改烂了 ...

多端互踢很多人的定义不一样，有的人希望多端直接互踢，而且的人可能希望移动端互踢，pc端互踢，但pc端和移动端可以并存。  这些具体的逻辑如果只选一种做到sdk里就显的很局限。所以，众口难调，就没有武断地去考虑这个实现。

我在2楼的回复，其实是考虑的最简单的那种，就是只要在别的端登陆就被踢。这个时间戳就是在你MobileIMSDK这一层，连接/登陆到服务端时，由服务端把当前的系统时间戳给你就是了，你去读一读代码，没有看源码的话，具体有点记不太清了

引用：freeman 发表于 2019-08-05 11:06
会不会有这种情况：
A设备已登录
B设备请求登录

不可能，因为有你的“A设备已登录”这个前提在，所以它拿着登陆时服务端给的时间戳是不可能晚于后面的时间。

引用：JackJiang 发表于 2019-08-05 11:28
不可能，因为有你的“A设备已登录”这个前提在，所以它拿着登陆时服务端给的时间戳是不可能晚于后面的时 ...

明白了，时间戳是上一次成功连接的时间戳，刚才理解错了，以为是当前请求的时间

引用：freeman 发表于 2019-08-05 11:30
明白了，时间戳是上一次成功连接的时间戳，刚才理解错了，以为是当前请求的时间

嗯嗯

我做的多端登录互踢现在还存在一个偶尔发生的问题：客户端在没有多端登录的情况下收到下线指令。
我怀疑这种情况导致，你看看有没有可能：
客户端断线，带着时间戳发送重连请求，服务端收到后更新时间戳，将新的结果返回给客户端，
因为重连请求是每隔3秒钟就发送，3秒之内服务端返回的新的结果尚未到达客户端，此时客户端再次发出一条重连请求，而此时服务端保存的时间戳已经更新了，而客户端发来的请求还是旧的时间戳，于是判断为失效连接，发出下线指令，于是...客户端被自己踢下线了

引用：freeman 发表于 2019-08-28 23:15
我做的多端登录互踢现在还存在一个偶尔发生的问题：客户端在没有多端登录的情况下收到下线指令。
我怀疑这 ...

应该不存在你说的这种可能，因为你重连时是会带上时间戳的，换句话说，服务端看到有时间戳带过来，就可以判定为这是这是重连，重连是不应更新时间戳的。

也就是第二条返回结果（下线）先于第一条（重连成功）到达客户端，导致客户端下线

引用：JackJiang 发表于 2019-08-28 23:21
应该不存在你说的这种可能，因为你重连时是会带上时间戳的，换句话说，服务端看到有时间戳带过来，就可以 ...

哦，是了，重连不更新时间，这个逻辑有点乱，我再理一理

引用：freeman 发表于 2019-08-28 23:25
哦，是了，重连不更新时间，这个逻辑有点乱，我再理一理

最好画个图，先把逻辑理顺了再去看代码就很清晰了。事情看起来很简单，但逻辑其实很绕的

原因找到了
if(a)
{
        if(b)
        {
                ...
        }
}
else
{
        ...
}
简写成
if(a && b)
{
        ...
}
else
{
        ...
}
逻辑错了。
重连更新时间戳目前看倒没问题，不过不更新更安全点。先不改了，有问题再取消更新