getwayworker中client_id问题

lbfeng 2023-07-29

问题描述

用getwayworker和手表端建立一个长连接，手表每次开机会给服务器发过来登录包，登录包里面还有设备id，后面的数据不会再有设备id，服务器进行相关处理绑定client_id和设备id并记录,以后接收的数据依靠client_id区分是哪台设备。现在遇到一个问题，这个client_id突然发生变化，导致在系统中根据此client_id找不到相应的设备id，并且长时间由于之前的client_id没有数据传输断开连接，这个手表的数据没有办法再进行判断存储。其实就是手表扔和服务器进行着连接，client_id在没有经过登录包情况下突然发生变化导致系统根据这个新的client_id找不到设备，致使这台设备的数据也就中断。有没有大神遇到过这种问题，知道怎么解决

![](/upload/img/20230729/2964c48ecee16a.png)

 1041  5 0

5个回答

efnic 2023-07-29

设备端的手表，向getwayworker发起连接，getwayworker返回client_id，uniqid等
手表端向API接口发起绑定请求，请求包含getwayworker下发的2个参数、以及手表本身的设备id等参数
设备端的手表，需要做心跳，每隔x秒，给服务器发送一个ping；
getwayworker在收到ping时，给手表回复一个pong
手表端的长连接断线时，重复步骤1.

凭设备id，向手表推送数据。

efnic 2023-07-29

参考官方的这一篇文档：https://www.workerman.net/doc/gateway-worker/work-with-other-frameworks.html

muyu 2023-07-29

client_id变了说明连接断了，重新发起链接了，可以在close和connect里面重新处理client_id和设备id的关系映射

暂无评论

Gin 2023-07-29

存session https://www.workerman.net/doc/gateway-worker/session.html

暂无评论

admin 2023-07-29

clientID是一个 buff，内部包含了gateway的ip端口和numIndex 打包压缩成hex的，你可以反向解析

暂无评论

latin 2023-07-29

业务不应该依赖client_id，应该依赖设备id。client_id是一个临时id，不应该存储使用。
正确做法，设备发起登录时利用 Gateway::bindUid($client_id, $设备id); 绑定，
然后以后所有操作都是操作设备id，比如发送信息用 Gateway::sendToUid($设备id, 数据),
判断设备是否在线用 Gateway::isUidOnline(设备id);

lbfeng 2023-07-31

Gateway::bindUid($client_id, $设备id)这个我已经绑定过，如果通过服务器给手表下发指令是可以直接用设备id下发的，还有一个就是要接收设备传出过来的tcp数据，不知道什么情况这个接收数据老是中断，现在排查出来的原因是两个：（1）设备网络不好会断开（2）传输过来的数据连接id突然发生变化，这个是在没有发生登录情况下连接id变了，没办法发生绑定关系，所以系统拿着这个连接id找不到相应的设备致使传输数据中断
efnic 2023-08-01

对接长连接，有几个基本操作：
1.连接时候用设备id和客户端id，请求接口绑定；
2.做好心跳
3.做好重连机制（低段位的肯定在onClose注册个断线重连，这种基本就是傻）
efnic 2023-08-01

重连机制：
1.创建一个全局生命周期的定时器（注意只能创建一次，无限制创建定时器客户端会崩）
2.连接建立后，周期性的每30s向服务器发送心跳包，比如ping
3.服务器收到客户端心跳包ping时，回复pong
4.客户端仅记录最后收到pong的时间戳
4.由全局定时器检查网络状况是否良好
if (lastPong + 30 *1.5 < now) {
//超时重连 todo
}
lbfeng 2023-08-01

谢谢啦知道是设备的连接id突然变了导致的，但是没找下好的解决办法，我尝试把新的连接id摧毁，发现摧毁后设备会重新自动发起连接，倒是也能解决我的问题，谢谢大神的方案
lbfeng 2023-08-01

由于手表端系统不是我们开发的，他们的心跳也给的是10分钟一次，排查受限，只能从服务器端入手