[已回复] 如何正确地理解MobileIMSDK服务器分配的唯一ID？

Jack Jiang于20171213日补充说明：
服务端为用户生成user_id的策略只存在于MobileIMSDK v2.x版中，v3版中不再需要由用服务端生成user_id哦！

有关服务器分配唯一ID的问题

问题：
大家好，新手看IM的代码，发现一个问题请教大家。我们客户度向服务器连接的时候，每次都会分派一个新ID。某个客户度再次登录的时候，我们怎么知道是谁登录了？从另外一个客户端上，怎么获得这个客户端的新ID？
例如;A第一次登录10003，B登录10004；A再次登录变成10005，那么B是不知道A的新ID的，B怎么和A通信？

学习学习

引用：wetnt 发表于 2016-09-09 13:15
总结下坛主说的：
一、想获得固定ID需要改写SDK服务端。
二、如不想改写SDK，就需要自己扩充现有客户端， ...

你的理解差不多，但还是不太对，你还没有看服务端Demo源码，无论是实现自已的user_id还是通过回调实现自已的用户名和user_id映射关系列表都是不需要去改SDK源码的（否则那就不叫SDK了，跟环信、融云这些SDK是一样的道理，所有的东西都通过开放的接口替你留好了），也就是说没有源码的情况下，通过继承接口并set好相应的回调，框架底层会自动调用并回调给你。

总结下坛主说的：
一、想获得固定ID需要改写SDK服务端。
二、如不想改写SDK，就需要自己扩充现有客户端，通过监听服务器往来通信的方式，建立自己的ID应用层。

这样理解对么？

另外，发送到服务器的账户和密码，也没有接口能否输出、返回，对吧？

听我来给你解答。

1）MobileIMSDK的底层算法是通过什么标识或凭证来给指定连接（或者说用户）发送消息的？
就是通过这个user_id。也就是说：只要在你的应用层能拿到MobileIMSDK里用户的user_id，就可以通过MobileIMSDK服务端的sendData方法向指定连接（或者说用户）发送消息（或你自已约定的数据）。

2）MobileIMSDK为什么要让每个客户端每次登陆时都生成不一样的user_id？
其实MobileIMSDK的算法里，只要保证user_id是唯一就可以保证算法的正常运转，之所以每次生成不一样的id，是因为MobileIMSDK默认使用的就是一个简单的全局自增int变量暂存了上次生成的id（我也不想把事情复杂化，反正越简单越好），目的非常简单：就是为了保证每次生成的id是唯一，仅此没有其它更多的考量。

3）MobileIMSDK能否每次生成一个固定的user_id？
答案是肯定的，你可以通过重写服务端留出来的接口实现自已的user_id生成策略就行了，前提要求只有一个：你要保证这个user_id是唯一的，就能保证MobileIMSDK的框架算法正常运行不受你自定义的影响。具体实现方法请参考服务端开发者指南的附录部分：http://www.52im.net/thread-63-1-1.html。

比如：你的user_id可以是你登陆的用户名对应你业务系统里的DB用户表里的主键id（这肯定是唯一且不变的），返回这个user_id你只需要通过重写MobileIMSDK的id生成方法，通过查询你的DB用户表就可以实现了。当然，具体怎么生成这个user_id由你自已决定，只要保证唯一即可。

4）MobileIMSDK每次生成一个唯一的user_id有什么好处？
好处很多，这意味着你应用层提交的这个用户名可以是任意值，甚至重复也不要紧，从而可以让MobileIMSDK框架用于：聊天室（注意聊天室里的人名可能是重复的哦）、推送（为了偷懒，用户名可简单随便填一个值就行）、聊天等不同的场景下，从而极到减小应用层对“用户名”定义的干扰，保持MobileIMSDK算法的独立性和内聚、重用性，降低SDK使用者的门槛：怎么用都能正常通信。

5）换个角度看：假设MobileIMSDK每次就简单的用你提交的登陆名作为整个框架算法的通信标识会怎么样？
其实可以这么做，但这将导致：你用同一个用户名重复登陆的话，前面的用户名肯定会被后面的给覆盖，也就意味着MobileIMSDK这一层要实现重复登陆踢掉线这样的算法策略，而这其实是应用层需要考虑的问题：因为每种应用对重复登陆的处理可能都不一样，MobileIMSDK这一层来实现的话就会限制它的应用范围和场景（比如：聊天室里用相同的名字，肯定就不能正常聊天了）。

所以，当时是基于以上才考虑，才来在底层来实现这个与上层用户名（更准确地说是业务层的逻辑）独立的user_id来保证通信的独立性。

6）我无法自定义生成我自已的唯一的user_id，该怎么用MobileIMSDK 来实现一个聊天应用里的一对一通信呢？
其实，MobileIMSDK一开始就没指望用户自定义生成自已的user_id策略，因为很多时候用户业务层的用户表主键可能并不是int这样的整型（很可能直接就是用户名），这就没法用了。基于这种情况，用户在不实现自已user_id生成策略的情况，使用MobileIMSDK实现聊天应用的时候，可以在你的应用层，通过监听MobileIMSDK的上线、下线回调，来实现一个你业务层用户名和底层user_id的对应关系（要能是一个hashmap），这样业务层要发送消息时可以通过用户名（当然通过user_id就更直接了，就不需要先查这个对应关系表来找到user_id了）查到它对应的user_id从而实现通信。换句话话说，对于重复登陆的问题，你自已就得要处理了，比如重复登陆直接踢掉线。