client_id為什么會(huì)變
設(shè)備連上gateway后，為什么會(huì)一直變化，我這邊監(jiān)聽設(shè)備指令，一個(gè)小時(shí)左右client_id就會(huì)變化
2個(gè)回答
http://m.wtbis.cn/q/5625
這里有變化的解決辦法
打賞
client_id固定為20個(gè)字符的字符串，用來全局標(biāo)記一個(gè)socket連接，每個(gè)客戶端連接都會(huì)被分配一個(gè)全局唯一的client_id。
如果client_id對(duì)應(yīng)的客戶端連接斷開了，那么這個(gè)client_id也就失效了。當(dāng)這個(gè)客戶端再次連接到Gateway時(shí)，將會(huì)獲得一個(gè)新的client_id。也就是說client_id和客戶端的socket連接生命周期是一致的。
client_id一旦被使用過，將不會(huì)被再次使用，也就是說client_id是不會(huì)重復(fù)的，即使分布式部署也不會(huì)重復(fù)。
文檔有寫
-
dou號(hào) 2024-09-29我的設(shè)備是一直處于上電狀態(tài)，從打印日志來看，設(shè)備和Gateway的連接一直處于斷開，重連，斷開再重連的狀態(tài)，請(qǐng)問這是因?yàn)槲以O(shè)備的通信不穩(wěn)定導(dǎo)致的，還是gateway本身的機(jī)制導(dǎo)致的，又或者說是socket機(jī)制原因
-
-
-
-
-
-
dou號(hào) 2024-09-30
我這邊的設(shè)備每30分鐘左右就會(huì)發(fā)送一次登錄指令，現(xiàn)在的現(xiàn)象是第三次發(fā)送的登錄指令連的clientid變了，然后因?yàn)樵O(shè)備的clientid變了，經(jīng)過心跳時(shí)間后之前的clientid觸發(fā)onclose
-
walkor 2024-09-30
clientid變了只能說明客戶端發(fā)起了新的連接，沒有“因?yàn)閏lientid變了觸發(fā)了onclose”這種因果關(guān)系。
至于為什么設(shè)備重新發(fā)起連接需要你們自己定位下，例如斷電、斷網(wǎng)、邏輯bug都有可能。
另外外網(wǎng)環(huán)境尤其是弱網(wǎng)環(huán)境，連接經(jīng)常斷開是很正常的事情，設(shè)備做好重連即可。 -
dou號(hào) 2024-09-30
我這邊的監(jiān)控日志顯示是clientid先變化的，從id1變成id2，然后經(jīng)過兩個(gè)心跳時(shí)長(zhǎng)之后，大約兩分鐘，onclose里面打印到了之前的clientid信息id1
-
walkor 2024-09-30
這種情況很常見，比如設(shè)備斷電，服務(wù)端不會(huì)立刻感知到設(shè)備連接斷開，需要心跳檢測(cè)后才能判斷設(shè)備的連接已經(jīng)無效，導(dǎo)致延遲觸發(fā)onclose。
再比如心跳間隔設(shè)置過長(zhǎng)例如大于等于1分鐘，連接可能會(huì)被路由節(jié)點(diǎn)或防火墻清除，導(dǎo)致服務(wù)端無法立刻感知連接已經(jīng)清理，也是需要心跳檢測(cè)，導(dǎo)致延遲觸發(fā)onclose。
再比如設(shè)備沒有關(guān)閉之前的連接，直接發(fā)起了新連接。服務(wù)端發(fā)現(xiàn)舊連接一直沒有心跳，則判斷連接斷開，延遲執(zhí)行onclose。
還有比如路由故障也會(huì)有類似效果。連接不是想象中的一方斷開，另外一方肯定知道，很多情況下不知道需要心跳檢測(cè)。 -
-
