[發明專利]一種鏈路保活方法及裝置

有效

• 申請號: 201610248207.X
• 申請日: 2016-04-20
• 公開（公告）號: CN107306282B
• 公開（公告）日: 2019-08-30
• 發明（設計）人: 劉威
• 申請（專利權）人: 中國移動通信有限公司研究院;中國移動通信集團公司
• 主分類號: H04L29/08
• 分類號: H04L29/08
• 代理公司: 北京派特恩知識產權代理有限公司 11270
• 代理人: 張穎玲;孟桂超

技術領域

本發明涉及移動互聯領域，尤其涉及一種鏈路保活方法及裝置。

背景技術

近些年來伴隨著移動網絡的升級和智能終端的普及，越來越多的終端應用程序出現了，特別是一些即時通信類、網絡電話(VoIP，Voice over Internet Protocol)類的應用，這些應用對實時性要求很高，需要時刻保持與后臺服務器的聯系，以便于其他用戶在想聯系時可以實時響應，所以這些應用需要永遠在線。

而目前保持在線的實現方式主要是通過建立應用和服務器之間的連接，并在一定間隔時間能和服務器之間通過發送、接收數據進行交互，而網絡中數據的接收和發送都是通過使用操作系統中的套接字(SOCKET)來實現的。因此保持在線就是判斷對應SOCKET是否已經斷開，而如何判斷對應SOCKET是否斷開，主要是依靠在系統中創建的心跳機制。心跳機制的基本思想是：通過發送心跳包來保持連接。換句話說，心跳包主要用于長連接的保活和斷線處理。

對于應用，一般會設置心跳包的發送間隔，然而，用戶的網絡接入條件不一，比如通過家里的WiFi網絡、公眾場合的WiFi網絡、或移動網絡等，加之有的網絡設置有防火墻有的未設置防火墻，不同網絡對數據鏈路的保持有不同的要求，因此大多數應用為了保持連接就會將心跳間隔設置的比較短，以便于保持在線狀態。

但是，在移動網絡情況下過多、過頻繁的信令消息會對移動網絡造成沖擊。因此如何解決因應用的頻繁心跳帶來的信令風暴是目前亟待解決的問題。

發明內容

為解決現有存在的技術問題，本發明實施例提供一種鏈路保活方法及裝置。

為達到上述目的，本發明實施例的技術方案是這樣實現的：

本發明實施例提供了一種鏈路保活方法，包括：

接收來自第一終端的第一保活消息；所述第一保活消息為針對第一應用對應鏈路的保活消息；

判斷所述第一終端所歸屬的第一基站是否滿足預設條件；所述預設條件表征所述第一基站為預設區域內的基站；

當所述第一基站滿足預設條件時，利用記錄的第一時刻，判斷是否允許發送所述第一保活消息；所述第一時刻為接入到所述預設區域內基站上的所述第一應用最后一次與應用服務器發生交互消息的時刻；

根據判斷結果，向所述應用服務器發送第一保活消息或者向所述第一終端返回保活響應。

上述方案中，所述利用記錄的第一時刻，判斷是否允許發送所述第一保活消息，包括：

利用所述第一時刻及第一發送間隔，判斷是否允許發送所述第一保活消息；所述第一發送間隔為針對所述第一應用的保活消息的發送間隔。

上述方案中，所述利用所述第一時刻及第一發送間隔，判斷是否允許發送所述第一保活消息，包括：

將所述第一時刻與所述第一發送間隔求和，得到第二時刻；

將當前時刻與所述第二時刻進行比較，當前時刻小于等于所述第二時刻時，允許發送所述第一保活消息；

當前時刻大于所述第二時刻時，不允許發送所述第一保活消息。

上述方案中，所述方法還包括：

當向所述應用服務器發送所述第一保活消息后，更新第一時刻為發送所述第一保活消息的時刻。

上述方案中，所述更新第一時刻為發送所述第一保活消息的時刻后，所述方法還包括：

所述第一應用向所述應用服務器發送除保活消息外的其它交互消息或接收到應用服務器的交互消息后，更新所述第一時刻為最后一次與應用服務器發生交互消息的時刻。

上述方案中，當未記錄所述第一時刻時，所述方法還包括：

向所述應用服務器發送所述第一保活消息，并記錄所述第一時刻為發送所述第一保活消息的時刻。

本發明實施例還提供了一種鏈路保活裝置，包括：

接收單元，用于接收來自第一終端的第一保活消息；所述第一保活消息為針對第一應用對應鏈路的保活消息；

位置分析單元，用于判斷所述第一終端所歸屬的第一基站是否滿足預設條件；所述預設條件表征所述第一基站為預設區域內的基站；

鏈路保活策略單元，用于當所述第一基站滿足預設條件時，利用記錄的第一時刻，判斷是否允許發送所述第一保活消息；所述第一時刻為接入到所述預設區域內基站上的所述第一應用最后一次與應用服務器發生交互消息的時刻；

心跳處理單元，用于根據判斷結果，向所述應用服務器發送第一保活消息或者向所述第一終端返回保活響應。

上述方案中，所述裝置還包括：