這是近期參與的乙個雲推送專案調研的一點東西，貼上來做個備份：）
綜述為了保持這個長連線不被防火牆刪除，需要在沒有資料傳送時，通過週期的傳送心跳資訊來保持會話連續。即心跳的目的：
心跳機制對於客戶端來說，是需要付出一些代價的，比如：
要減少損耗，一方面要減少每次心跳傳送的資料量，更重要的是要減少傳送心跳包的次數，因此心跳週期的設定成為關鍵要素：
所以需要進行權衡，找到乙個最合適的心跳時間，但由於網路情況的複雜，我們無法預先知道這個最合適的時間，所以需要找到一種自適應(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管理，又...