为啥不能自定义client_id

sonsnf 更新于2015-08-26

为啥不能自定义client_id，个人感觉例如一些涉及会员的应用的，如果自己定义client_id，会少很多麻烦

 6275  2 0

2个回答

walkor 2015-06-23

打赏

实际上GatewayWorker 2.1.4之前的版本是支持自定义client_id的，但是出现了很多问题，后来改成不可自定义，并且全局自增。

client_id 用来全局标记一个socket连接，是一个全局自增的数值，由此可以精确控制向哪个socket连接发送数据，由于client_id自增，即使向过期的client_id发送数据不会造成影响。

client_id交给开发者自定义，难免会导致client_id重复，而client_id重复，会导致部分socket失效或者断开，也无法确定向哪个socket连接发送数据，导致应用异常，而这样的异常很难排查。

一般开发者会想把client_id定义为uid，这样会导致业务处理困难或者业务异常。举几个例子
1、聊天客户端与wm（GatewayWorker）建立连接，这时客户端突然断网然后重新发起一个连接，而在wm这边由于客户端异常断网，没立即收到连接断开的fin包，wm这边就有两个uid的连接，当wm终于检测到第一个连接断开时，会触发onClose($uid)，这时可能会认为uid下线了，做一些下线处理操作，但是实际上这个uid还有一个连接，并没有下线，导致业务异常。

2、如果把client_id定义为uid，假设用户打开了两个socket连接，那么会导致其中的一个连接失效，无法收到数据，典型的例子是两个聊天室的连接id都是uid，则只有一个聊天室能收到消息，另外一个收不到消息，或者可能在这个聊天室给uid发送消息，但是另外一个聊天室也收到了。同样如果这个用户退出了其中的一个聊天室，onClose($uid)只能知道这个uid退出了，但是不知道退出的是哪个聊天室，导致业务编程困难。

3、如果把client_id定义为uid，无法实现多客户端通讯，像PC QQ 和手机QQ同时在线是需要两条socket连接的，必须需要分开标记的，如果都统一用uid，则无法针对某个客户端推送消息，也无法方便的判断消息是从哪个平台的客户端发来的。

即使不用uid标记client_id
如果client_id自定义不当，会引发逻辑错误，比如用户A上线后client_id为1，这时要向client_id为1的的连接发送数据，恰巧A用户还没收到数据就下线了，B用户上线，也被分配client_id=1，则会导致发给A用户的数据却发给了B，导致业务异常

结论
client_id为自增并且短时间内不重复是非常必要的，而达到这点的client_id的值对于开发者来说也没有什么意义，反而交给开发者定义会出现很多不可预知的问题，并且很难排查。

关于和现有账号绑定问题，GatewayWorker后面会考虑增加一组接口，用来绑定uid与client_id的关系，在client_id下线时自动解绑，绑定关系存储在Gateway的内存中，不用读存储，效率很高。接口类似如下：

Gateway::bindUid($client_id, $uid); // 将$client_id绑定到uid下，uid与client_id是一对多关系
Gateway:;sendToUid($msg, $uid); // 给这个uid下的所有链接发送数据