摘要:如何構建商業級別聊天系統篇五保活,請不要讓你的服務變成小豬佩奇特關人上人擱淺神秘連接哥哥姐姐弟弟妹妹叔叔阿姨們說點閑話保活,不光是對于來說需要保活,其實我們很多的系統,在需要確定對方是否處于可通信狀態的時候都是需要這種保活機制。
特關人上人!dying 擱淺 神秘連接
哥哥姐姐弟弟妹妹叔叔阿姨們~
keep alive 保活,不光是對于 MQTT 來說需要保活,其實我們很多的系統,在需要確定對方是否處于可通信狀態的時候都是需要這種保活機制。比如音頻聊天,那么音頻聊天的雙方和服務器端同樣也是需要一套 keep alive 保活的機制來確定雙方的狀態以便進行相應的處理。
了解 keep alive 對于系統設計來說是具備指導性意義。
為什么需要保活?
TCP 半開連接問題 half-open 。
首先 MQTT 是基于 TCP 協議的,那么 TCP 的特性同樣適用于 MQTT :可靠、有序、錯誤檢測。
然而使用 TCP 連接的通信雙方之間的傳輸有時不會同步。
例如,通信過程中一方崩潰或者傳輸錯誤,這種不完全連接的狀態稱為 ”half-open“
那么此時的問題就是,通信雙方,一方崩潰并不會通知另一方,那么仍然連接的一方會繼續請求并等待回復。這顯然對于仍然連接的一方是體驗很差的,或者說不合理的。
對于此 MQTT 的發明者 Andy Stanford-Clark 是如此解釋的。
進一步說明規范的內容,keepalive 的目的是讓應用程序 級別(客戶端應用程序和代理)可以知道底層連接仍然是端到端的。
盡管理論上 TCP/IP 會在 socket 中斷時通知你,但實際上,特別是在移動和衛星鏈接等情況下,通常會通過空中 “偽造” TCP 并在每一端放回標頭,極有可能 TCP 會話到“黑洞”,即它似乎仍然打開,但實際上只是將你寫入的任何內容傾倒在地板上。
因此,keepalive 會確認你確實仍在與代理交談(并且從代理端,客戶端確實仍處于連接狀態),特別是當處于長時間連接的連接上時,或者訂閱了不常發布的主題,或在 qos0(即無確認)發布給 borker 代理。
應使用(由 MQTT 庫)從代理返回的響應客戶端啟動的“ping-req”的 ping-resp(“pong”!)來告訴應用程序連接是否已消失,或觸發重新連接。
那么 MQTT 包含了這樣一個 ”保活“ 的功能,該功能為 half-open 問題提供了一個解決方案,或者說一個評估連接是否斷開的依據。
keep alive 確認 broker 代理 和 client 客戶端 之間的連接仍然打開,并且 broker 和 client 之間是可以感知到彼此是有連接的
具體操作就是,當客戶端與服務端建立連接后,客戶端向服務端進行以秒為間隔的通訊,這個時間間隔定義了,客戶端和服務器沒有通訊的最大時長。
MQTT 這樣對其定義:
“The Keep Alive … is the maximum time interval that is permitted to elapse between the point at which the Client finishes transmitting one Control Packet and the point it starts sending the next. It is the responsibility of the Client to ensure that the interval between Control Packets being sent does not exceed the Keep Alive value. In the absence of sending any other Control Packets, the Client MUST send a PINGREQ Packet.”
即: keep alive 是客戶端完成發送數據包的時間點到下一個發送數據包的時間點所允許經過的最大時間間隔,準確發送 PINGREQ 數據包是客戶端的責任。
只要消息交換頻繁,且在 keep alive 所定義的時間范圍內,就不需要發送額外的消息來確認連接。
但如果,在此期間,客戶端沒有發送消息,它必須發送一個 PINGREQ 數據包 來確認 客戶端和代理雙方都是可用的狀態。
代理如果在 1.5 倍的 keep alive 時間間隔中 沒有收到客戶端的任何消息或者 PINGREQ 保活數據包,則斷開客戶端連接。同樣的對于 客戶端,在合理的時間內沒有收到代理的響應也應該關閉連接。
keep alive 功能使用兩個數據包來保證: PINGREQ 和 PINGRESP
PINGREQ 由客戶端發送,無有效負載,客戶端可以在任何時候發送該包來確認連接狀態。
當服務端收到 PINGREQ 數據包時,必須回復一個 PINGRESP 數據包來表示其仍然可用,同樣的 PINGRESP 也不包含有效負載
通常,客戶端斷開連接后可能會重新連接。有時 broker 服務器仍然會提供 half-open 半開連接給客戶端(如在 1.5 倍的 keep alive 間隔內,客戶端嘗試斷線重連,此時就會有兩個客戶端連接),在 MQTT 中,如果 broker 代理檢測到了 半開連接,則會執行 客戶端接管,borker 會斷開先前的連接,并和客戶端建立新的連接,這一行為保證了 半開連接 不會阻止客戶端斷線重連。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/118879.html
摘要:如何構建商業級別聊天系統篇四特性之持久會話保留消息遺囑本篇將介紹的一些我們應該關注的特性關注不迷路我是擱淺神秘地址持久會話為什么需要持久會話為了接收的消息,客戶端在連接時會創建其感興趣主題的訂閱。代理僅存儲每個主題的一條保留消息。 ...
摘要:一個輕量級高效率的支持聊天與物聯網的通訊框架從月初到現在已經大約已經三個月了,由于一直沒有時間與精力很好的維護這個項目,心里一直有所歉意。希望本項目對你有所幫助,我的目標暫定,一個小眾加物聯網的開源通訊項目。 篇幅較長,感謝閱讀。 萬事開頭難 在我決定做開源是因為自身工作接觸到大多數的項目都是基于開源大佬寫的框架,自覺慚愧,工作以來一直忙于業務與功能實現,多多少少做過的幾個項目也沒能抽...
摘要:本文是其中的一個解決方案。地址客戶端服務端前端網頁介紹,消息隊列遙測傳輸是開發的一個即時通訊協議,有可能成為物聯網的重要組成部分。必須用于在頂層分隔符之后,除了當自己指定時。 1. 問題描述 最近,本實驗室大量上馬云測量,云監控方面的項目,大概是屬于物聯網應用的一個分支。老板也有將舊有儀器改造的想法,所以要實現儀器設備的云控制。本文是其中的一個解決方案。 2. 技術選型 消息隊列:M...
摘要:教程傳送門基于平臺開發連接巴法云簡介實驗準備硬件軟件實驗步驟點燈實驗發送溫濕度指令升級總結關于巴法云專注于開源,智造,創新,分享。 Arduino教程傳送門????...
閱讀 2562·2021-09-02 15:40
閱讀 1565·2019-08-30 15:54
閱讀 1079·2019-08-30 12:48
閱讀 3398·2019-08-29 17:23
閱讀 1046·2019-08-28 18:04
閱讀 3664·2019-08-26 13:54
閱讀 606·2019-08-26 11:40
閱讀 2390·2019-08-26 10:15