设备连上gateway后,为什么会一直变化,我这边监听设备指令,一个小时左右client_id就会变化
https://www.workerman.net/q/5625 这里有变化的解决办法
您知道client_id为什么会变吗
好像每次新连接都会生成一个新的ID,不过我没用过Gateway,你可以@一下作者或者在群里面问问。
方便把群号发我吗
client_id固定为20个字符的字符串,用来全局标记一个socket连接,每个客户端连接都会被分配一个全局唯一的client_id。
如果client_id对应的客户端连接断开了,那么这个client_id也就失效了。当这个客户端再次连接到Gateway时,将会获得一个新的client_id。也就是说client_id和客户端的socket连接生命周期是一致的。
client_id一旦被使用过,将不会被再次使用,也就是说client_id是不会重复的,即使分布式部署也不会重复。
文档有写
我的设备是一直处于上电状态,从打印日志来看,设备和Gateway的连接一直处于断开,重连,断开再重连的状态,请问这是因为我设备的通信不稳定导致的,还是gateway本身的机制导致的,又或者说是socket机制原因
平均多久断开重连一次?
一个小时左右
可能是没加心跳导致的连接断开,建议50秒一个心跳维持连接。心跳间隔不能超过一分钟
心跳是有的,所以正常情况下设备连接上gateway,其clientid基本就保持不变了是吗
clientid就是连接id,连接一直不断开就不变,断开就新生成一个clientid
我这边的设备每30分钟左右就会发送一次登录指令,现在的现象是第三次发送的登录指令连的clientid变了,然后因为设备的clientid变了,经过心跳时间后之前的clientid触发onclose
clientid变了只能说明客户端发起了新的连接,没有“因为clientid变了触发了onclose”这种因果关系。 至于为什么设备重新发起连接需要你们自己定位下,例如断电、断网、逻辑bug都有可能。 另外外网环境尤其是弱网环境,连接经常断开是很正常的事情,设备做好重连即可。
我这边的监控日志显示是clientid先变化的,从id1变成id2,然后经过两个心跳时长之后,大约两分钟,onclose里面打印到了之前的clientid信息id1
这种情况很常见,比如设备断电,服务端不会立刻感知到设备连接断开,需要心跳检测后才能判断设备的连接已经无效,导致延迟触发onclose。 再比如心跳间隔设置过长例如大于等于1分钟,连接可能会被路由节点或防火墙清除,导致服务端无法立刻感知连接已经清理,也是需要心跳检测,导致延迟触发onclose。 再比如设备没有关闭之前的连接,直接发起了新连接。服务端发现旧连接一直没有心跳,则判断连接断开,延迟执行onclose。 还有比如路由故障也会有类似效果。连接不是想象中的一方断开,另外一方肯定知道,很多情况下不知道需要心跳检测。
这个是tcp基础
https://www.workerman.net/q/5625
这里有变化的解决办法
您知道client_id为什么会变吗
好像每次新连接都会生成一个新的ID,不过我没用过Gateway,你可以@一下作者或者在群里面问问。
方便把群号发我吗
client_id固定为20个字符的字符串,用来全局标记一个socket连接,每个客户端连接都会被分配一个全局唯一的client_id。
如果client_id对应的客户端连接断开了,那么这个client_id也就失效了。当这个客户端再次连接到Gateway时,将会获得一个新的client_id。也就是说client_id和客户端的socket连接生命周期是一致的。
client_id一旦被使用过,将不会被再次使用,也就是说client_id是不会重复的,即使分布式部署也不会重复。
文档有写
我的设备是一直处于上电状态,从打印日志来看,设备和Gateway的连接一直处于断开,重连,断开再重连的状态,请问这是因为我设备的通信不稳定导致的,还是gateway本身的机制导致的,又或者说是socket机制原因
平均多久断开重连一次?
一个小时左右
可能是没加心跳导致的连接断开,建议50秒一个心跳维持连接。心跳间隔不能超过一分钟
心跳是有的,所以正常情况下设备连接上gateway,其clientid基本就保持不变了是吗
clientid就是连接id,连接一直不断开就不变,断开就新生成一个clientid
我这边的设备每30分钟左右就会发送一次登录指令,现在的现象是第三次发送的登录指令连的clientid变了,然后因为设备的clientid变了,经过心跳时间后之前的clientid触发onclose
clientid变了只能说明客户端发起了新的连接,没有“因为clientid变了触发了onclose”这种因果关系。
至于为什么设备重新发起连接需要你们自己定位下,例如断电、断网、逻辑bug都有可能。
另外外网环境尤其是弱网环境,连接经常断开是很正常的事情,设备做好重连即可。
我这边的监控日志显示是clientid先变化的,从id1变成id2,然后经过两个心跳时长之后,大约两分钟,onclose里面打印到了之前的clientid信息id1
这种情况很常见,比如设备断电,服务端不会立刻感知到设备连接断开,需要心跳检测后才能判断设备的连接已经无效,导致延迟触发onclose。
再比如心跳间隔设置过长例如大于等于1分钟,连接可能会被路由节点或防火墙清除,导致服务端无法立刻感知连接已经清理,也是需要心跳检测,导致延迟触发onclose。
再比如设备没有关闭之前的连接,直接发起了新连接。服务端发现旧连接一直没有心跳,则判断连接断开,延迟执行onclose。
还有比如路由故障也会有类似效果。连接不是想象中的一方断开,另外一方肯定知道,很多情况下不知道需要心跳检测。
这个是tcp基础