为啥不能自定义client_id

sonsnf

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

5699 2 0
2个回答

walkor

实际上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下的所有链接发送数据

  • 暂无评论
walkor
  • 暂无评论
年代过于久远,无法发表回答
🔝