智慧型心跳調研和初步設計

2021-06-28 00:33:56 字數 1005 閱讀 4060

這是近期參與的乙個雲推送專案調研的一點東西,貼上來做個備份:)

綜述為了保持這個長連線不被防火牆刪除,需要在沒有資料傳送時,通過週期的傳送心跳資訊來保持會話連續。即心跳的目的:

心跳機制對於客戶端來說,是需要付出一些代價的,比如:

要減少損耗,一方面要減少每次心跳傳送的資料量,更重要的是要減少傳送心跳包的次數,因此心跳週期的設定成為關鍵要素:

所以需要進行權衡,找到乙個最合適的心跳時間,但由於網路情況的複雜,我們無法預先知道這個最合適的時間,所以需要找到一種自適應(adaptive)的智慧型演算法來進行猜想。

初步設計

首先需要確定心跳間隔的最小值min和最大值max,單位為秒,這是我們經過演算法得到的心跳間隔不可以超過這個範圍。

max和min的確定需要經過實際的統計和測試才能得出,可先初步指定,後續酌情設定,最終的心跳時間會落在這個範圍之內。

演算法在客戶端上實現,因為心跳訊息是由客戶端發起的,只有客戶端能檢測到心跳訊息的傳送失敗。

演算法流程簡述如下:

1)客戶端請求goload介面,得到上述提到的min和max,還有t和n和m,後續會介紹。

客戶端還需維護3個變數,分別為:當前的心跳間隔cur,min'和max',後續會介紹到。

初始設定如下:

2)連線tcp server,第一次傳送心跳後間隔cur時間後傳送第二次心跳。

3)如果第二次傳送後服務端響應成功,那麼代表網路順暢且當前的時間間隔沒有被nat殺掉,那麼更新資料:

4)以cur作為心跳間隔繼續傳送心跳。

5)如果傳送心跳沒有得到服務端響應(客戶端應會設定乙個read超時時間,需要酌情設定),則代表出現網路問題,可能是網路擁塞出現了讀超時,那麼客戶端可以重新試圖傳送心跳n次,間隔為m秒,n和m酌情設定,如果發現還是超時,則嘗試重連;也可能是當前的心跳間隔比nat會話時間大,或者是裝置的網路不可用,那麼需要進行重連,重連前需要更新下列資料並回到第2個步驟:

6)在經過了若干次計算之後,會得到乙個最優的心跳間隔,之後就不需要進行計算了,條件如下:

結論

智慧型心跳調研和初步設計

這是近期參與的乙個雲推送專案調研的一點東西,貼上來做個備份 綜述為了保持這個長連線不被防火牆刪除,需要在沒有資料傳送時,通過週期的傳送心跳資訊來保持會話連續。即心跳的目的 心跳機制對於客戶端來說,是需要付出一些代價的,比如 要減少損耗,一方面要減少每次心跳傳送的資料量,更重要的是要減少傳送心跳包的次...

初步設計演算法

兩道題目 1.編寫乙個函式,接受兩個字串指標引數。如果第二個字串被包含在第乙個字串中,函式就返回被包含的字串開始的位址,否則函式返回空指標。2.編寫乙個函式,引數為乙個字串,函式刪除字串中的空格。並顯示結果。分析 第一道題目中顯然得有雙重遍歷,第一重是對第乙個字串依次遍歷 第二重是對針對第一字串中的...

GameFramework的初步設計

最近這幾天在搞乙個gameframework,其實就是在引擎基礎上增加乙個遊戲框架,對遊戲進行抽象,對引擎使用的一些封裝。在進行具體設計的時候很多細節問題是值得思考的。總結如下 總的來說我所設計的遊戲框架從功能上來講就是兩件事,乙個是遊戲的狀態管理 什麼選單狀態,遊戲狀態等等 在乙個就是ai管理,又...