本發(fā)明涉及通信技術(shù)領(lǐng)域，特別是涉及服務(wù)端與客戶端之間控制類消息的傳輸方法及系統(tǒng)。

背景技術(shù)：

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，終端中越來越多的應(yīng)用程序都需要服務(wù)端向客戶端(應(yīng)用程序)發(fā)送控制類消息，以保證客戶端的正常運(yùn)營，比如更新用戶信息、刷新頁面及同步服務(wù)端數(shù)據(jù)。

現(xiàn)有技術(shù)中，基于sip協(xié)議(sessioninitiationprotocol，會話初始化協(xié)議)的服務(wù)端向客戶端發(fā)送控制類消息，是通過客戶端主動發(fā)送請求來實(shí)現(xiàn)的。當(dāng)符合設(shè)定條件時，客戶端主動向服務(wù)端發(fā)送請求，服務(wù)端根據(jù)客戶端發(fā)送的請求，向客戶端發(fā)送控制類消息，例如，首次啟動app客戶端時客戶端主動發(fā)送一次請求，或者首次進(jìn)入某個頁面時客戶端主動發(fā)送一次請求。

但是，采用客戶端主動向服務(wù)端發(fā)送請求以獲取控制類消息的方法，會導(dǎo)致客戶端從同步完一次服務(wù)端發(fā)送的控制類消息，到下一次客戶端主動發(fā)送請求之間，無法接收到控制類消息，若在此期間服務(wù)端的控制類消息發(fā)生變化，客戶端無法及時獲取控制類消息。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明實(shí)施例的目的在于提供一種服務(wù)端與客戶端之間控制類消息的傳輸方法及系統(tǒng)，以實(shí)現(xiàn)客戶端及時獲取控制類消息。具體技術(shù)方案如下：

一種服務(wù)端與客戶端之間控制類消息的傳輸方法，應(yīng)用于基于sip協(xié)議的服務(wù)端，包括：

獲取待發(fā)送的控制類消息，確定所述控制類消息對應(yīng)的至少一類客戶端；

獲取應(yīng)用信息表，在所述應(yīng)用信息表中查找到所述控制類消息對應(yīng)的客戶端的信息，其中，所述應(yīng)用信息表標(biāo)識待控制的客戶端的信息；

根據(jù)查找到的所述控制類消息對應(yīng)的客戶端的信息，向查找到的所述控制類消息對應(yīng)的客戶端發(fā)送所述控制類消息。

可選的，在所述獲取待發(fā)送的控制類消息，確定所述控制類消息對應(yīng)的至少一類客戶端之前，所述方法還包括：

接收由所述客戶端發(fā)送的注冊包，其中，所述注冊包包括：所述客戶端所在的地址、所述客戶端所在的端口及所述客戶端的標(biāo)識；

根據(jù)所述注冊包，在所述應(yīng)用信息表中寫入所述待控制的客戶端的信息。

可選的，在所述獲取待發(fā)送的控制類消息，確定所述控制類消息對應(yīng)的至少一類客戶端之前，所述方法還包括：

接收由所述客戶端發(fā)送的心跳包，其中，所述心跳包標(biāo)識所述客戶端的運(yùn)行情況；

根據(jù)所述心跳包中所述客戶端的運(yùn)行情況，維護(hù)所述應(yīng)用信息表。

可選的，所述根據(jù)查找到的所述控制類消息對應(yīng)的客戶端的信息，向查找到的所述控制類消息對應(yīng)的客戶端發(fā)送所述控制類消息，包括：

步驟a，將查找到的所述控制類消息對應(yīng)的客戶端加入到目標(biāo)對象集合中，其中，所述目標(biāo)對象集合用于記錄所述控制類消息對應(yīng)的客戶端；

步驟b，根據(jù)查找到的所述控制類消息對應(yīng)的客戶端的信息，分別向所述目標(biāo)對象集合中的每個客戶端發(fā)送所述控制類消息；

步驟c，接收由所述目標(biāo)對象集合中的客戶端根據(jù)所述控制類消息發(fā)送的反饋信息，其中，所述反饋信息標(biāo)識發(fā)送所述反饋信息的客戶端已經(jīng)接收到所述控制類消息；

步驟d，將接收到的反饋信息所對應(yīng)的客戶端從所述目標(biāo)對象集合中清除；

步驟e，若所述目標(biāo)對象集合不為空，返回所述步驟b執(zhí)行，直至所述目標(biāo)對象集合為空，停止發(fā)送所述控制類消息；若所述目標(biāo)對象集合為空，停止發(fā)送所述控制類消息。

一種服務(wù)端與客戶端之間控制類消息的傳輸方法，應(yīng)用于基于sip協(xié)議的客戶端，包括：

接收由服務(wù)端根據(jù)應(yīng)用信息表發(fā)送的控制類消息，其中，所述應(yīng)用信息表標(biāo)識待控制的客戶端的信息。

可選的，在所述接收由服務(wù)端根據(jù)應(yīng)用信息表發(fā)送的控制類消息之前，所述方法還包括：

在啟動所述待控制的客戶端時，向所述服務(wù)端發(fā)送注冊包，以使所述服務(wù)端根據(jù)所述注冊包，在所述應(yīng)用信息表中標(biāo)識所述待控制的客戶端的信息，其中，所述注冊包包括：所述客戶端所在的地址、所述客戶端所在的端口及所述客戶端的標(biāo)識。

可選的，在所述接收由服務(wù)端根據(jù)應(yīng)用信息表發(fā)送的控制類消息之前，所述方法還包括：

向所述服務(wù)端發(fā)送心跳包，以使所述服務(wù)端根據(jù)所述心跳包維護(hù)所述應(yīng)用信息表，其中，所述心跳包標(biāo)識所述客戶端的運(yùn)行情況。

一種服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)，應(yīng)用于基于sip協(xié)議的服務(wù)端，包括：

控制類消息獲取模塊，用于獲取待發(fā)送的控制類消息，確定所述控制類消息對應(yīng)的至少一類客戶端；

信息表獲取模塊，用于獲取應(yīng)用信息表，在所述應(yīng)用信息表中查找到所述控制類消息對應(yīng)的客戶端的信息，其中，所述應(yīng)用信息表標(biāo)識待控制的客戶端的信息；

第一發(fā)送模塊，用于根據(jù)查找到的所述控制類消息對應(yīng)的客戶端的信息，向查找到的所述控制類消息對應(yīng)的客戶端發(fā)送所述控制類消息。

可選的，所述系統(tǒng)還包括：

第二接收模塊，用于接收由所述客戶端發(fā)送的注冊包，其中，所述注冊包包括：所述客戶端所在的地址、所述客戶端所在的端口及所述客戶端的標(biāo)識；

第一維護(hù)模塊，用于根據(jù)所述注冊包，在所述應(yīng)用信息表中寫入所述待控制的客戶端的信息。

可選的，所述系統(tǒng)還包括：

第三接收模塊，用于接收由所述客戶端發(fā)送的心跳包，其中，所述心跳包標(biāo)識所述客戶端的運(yùn)行情況；

第二維護(hù)模塊，用于根據(jù)所述心跳包中所述客戶端的信息，維護(hù)所述應(yīng)用信息表。

可選的，所述第一發(fā)送模塊，包括：

目標(biāo)對象集合確定子模塊，用于將查找到的所述控制類消息對應(yīng)的客戶端加入到目標(biāo)對象集合中，其中，所述目標(biāo)對象集合用于記錄所述控制類消息對應(yīng)的客戶端；

控制類消息發(fā)送子模塊，用于根據(jù)查找到的所述控制類消息對應(yīng)的客戶端的信息，分別向所述目標(biāo)對象集合中的每個客戶端發(fā)送所述控制類消息；

反饋信息接收子模塊，用于接收由所述目標(biāo)對象集合中的客戶端根據(jù)所述控制類消息發(fā)送的反饋信息，其中，所述反饋信息標(biāo)識發(fā)送所述反饋信息的客戶端已經(jīng)接收到所述控制類消息；

目標(biāo)對象更新子模塊，用于將接收到的反饋信息所對應(yīng)的客戶端從所述目標(biāo)對象集合中清除；

判定模塊子模塊，用于若所述目標(biāo)對象集合不為空，返回所述控制類消息發(fā)送子模塊執(zhí)行，直至所述目標(biāo)對象集合為空，停止發(fā)送所述控制類消息；若所述目標(biāo)對象集合為空，停止發(fā)送所述控制類消息。

一種服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)，應(yīng)用于基于sip協(xié)議的客戶端，包括：

第一接收模塊，用于接收由服務(wù)端根據(jù)應(yīng)用信息表發(fā)送的控制類消息，其中，所述應(yīng)用信息表標(biāo)識待控制的客戶端的信息。

可選的，所述系統(tǒng)還包括：

第二發(fā)送模塊，用于在啟動所述待控制的客戶端時，向所述服務(wù)端發(fā)送注冊包，以使所述服務(wù)端根據(jù)所述注冊包，在所述應(yīng)用信息表中標(biāo)識所述待控制的客戶端的信息，其中，所述注冊包包括：所述客戶端所在的地址、所述客戶端所在的端口及所述客戶端的標(biāo)識。

可選的，所述系統(tǒng)還包括：

第三發(fā)送模塊，用于向所述服務(wù)端發(fā)送心跳包，以使所述服務(wù)端根據(jù)所述心跳包維護(hù)所述應(yīng)用信息表，其中，所述心跳包標(biāo)識所述客戶端的運(yùn)行情況。

本發(fā)明實(shí)施例提供的服務(wù)端與客戶端之間控制類消息的傳輸方法及系統(tǒng)，服務(wù)端通過查詢應(yīng)用信息表，確定接收控制類消息的客戶端，并主動發(fā)送控制類消息，以實(shí)現(xiàn)客戶端及時獲取控制類消息。當(dāng)然，實(shí)施本發(fā)明的任一產(chǎn)品或方法并不一定需要同時達(dá)到以上所述的所有優(yōu)點(diǎn)。

附圖說明

為了更清楚地說明本發(fā)明實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實(shí)施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實(shí)施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸方法，應(yīng)用于服務(wù)端的流程示意圖；

圖2為本發(fā)明實(shí)施例的應(yīng)用信息表的示意圖；

圖3為本發(fā)明實(shí)施例的通過查詢應(yīng)用信息表，向客戶端發(fā)送控制類消息的示意圖；

圖4為本發(fā)明實(shí)施例的根據(jù)注冊包，維護(hù)應(yīng)用信息表的示意圖；

圖5為本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)，應(yīng)用于服務(wù)端的示意圖。

具體實(shí)施方式

下面將結(jié)合本發(fā)明實(shí)施例中的附圖，對本發(fā)明實(shí)施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實(shí)施例僅僅是本發(fā)明一部分實(shí)施例，而不是全部的實(shí)施例?；诒景l(fā)明中的實(shí)施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實(shí)施例，都屬于本發(fā)明保護(hù)的范圍。

需要說明的是，本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸方法及系統(tǒng)主要應(yīng)用于基于sip協(xié)議(sessioninitiationprotocol，會話初始化協(xié)議)的udp協(xié)議(userdatagramprotocol，用戶數(shù)據(jù)報協(xié)議)網(wǎng)絡(luò)中，當(dāng)然還可以應(yīng)用到基于sip協(xié)議的tcp協(xié)議(transmissioncontrolprotocol，傳輸控制協(xié)議)網(wǎng)絡(luò)中。

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，很多應(yīng)用程序(客戶端)都有一些控制方面的需求，例如，更新用戶信息，刷新頁面，及同步服務(wù)端數(shù)據(jù)?，F(xiàn)有技術(shù)中，基于sip協(xié)議的客戶端主動發(fā)送請求，基于sip協(xié)議的服務(wù)端收到客戶端發(fā)送的請求后返回控制類消息，例如，首次啟動app(application，應(yīng)用程序)時客戶端主動發(fā)送請求更新一次用戶信息，或者首次進(jìn)入某個頁面時客戶端主動發(fā)送請求從服務(wù)端同步一次數(shù)據(jù)。但是采用客戶端主動發(fā)送請求的方法，會存在更新不及時的情況，例如，在客戶端同步完服務(wù)端的數(shù)據(jù)之后，到下次客戶端主動發(fā)送請求以完成數(shù)據(jù)同步之前，若服務(wù)端的數(shù)據(jù)發(fā)生了變化，客戶端是沒有辦法及時同步的。

因此本發(fā)明實(shí)施提供了一種基于sip協(xié)議的服務(wù)端與客戶端之間控制類消息的傳輸方法，參見圖1，圖1為本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸方法的流程示意圖，包括：

s101，獲取待發(fā)送的控制類消息，確定控制類消息對應(yīng)的至少一類客戶端。

服務(wù)端推送控制類消息，可以向全局網(wǎng)絡(luò)中的所有app(application，應(yīng)用程序)進(jìn)行推送，也可以針對某些特定app(客戶端)進(jìn)行推送。控制類消息中標(biāo)識了該控制類消息推送的app，根據(jù)控制類消息，確定控制類消息對應(yīng)的app的種類，推送方式靈活。

s102，獲取應(yīng)用信息表，在應(yīng)用信息表中查找到控制類消息對應(yīng)的客戶端的信息，其中，應(yīng)用信息表標(biāo)識待控制的客戶端的信息。

提前建立的應(yīng)用信息表中記錄了待控制的app所在的ip地址(internetprotocoladdress，互聯(lián)網(wǎng)協(xié)議地址)，應(yīng)用信息表中還可以包括app所在的port(端口)。在實(shí)際應(yīng)用中，會有多個終端使用同一種app的情況，因此在應(yīng)用信息表中，一類app可能會對應(yīng)多組信息，每組信息標(biāo)識一個app的信息。應(yīng)用信息表的示意圖如圖2所示，appid(identification，身份標(biāo)識號)1對應(yīng)ip1port1(種類appid1對應(yīng)所在地址為ip1port1的一個客戶端)，appid2對應(yīng)ip1port4，ip2port2及ip5port5(種類appid2對應(yīng)所在地址為ip1port4，ip2port2及ip5port5的三個客戶端)。獲取應(yīng)用信息表，為后續(xù)根據(jù)應(yīng)用信息表查找控制類消息對應(yīng)的客戶端的信息提供了前提。

應(yīng)用信息表中記錄了待控制的客戶端的信息，根據(jù)控制類消息對應(yīng)的客戶端的種類，查找該類型的所有客戶端的信息。例如，參見圖2，在控制類消息對應(yīng)的客戶端的種類為appid2時，查找應(yīng)用信息表可得，appid2對應(yīng)的客戶端的地址為ip1port4、ip2port2及ip5port5，即控制類消息對應(yīng)的客戶端的消息為ip1port4、ip2port2及ip5port5。

s103，根據(jù)查找到的控制類消息對應(yīng)的客戶端的信息，向查找到的控制類消息對應(yīng)的客戶端發(fā)送控制類消息。

參見圖3，在控制類消息對應(yīng)的客戶端為客戶端c1：ip1port4、客戶端b1：ip2port2及客戶端d1：ip5port5時，向客戶端b1、客戶端c1及客戶端d1發(fā)送控制類消息。

在本發(fā)明實(shí)施例中，服務(wù)端通過查詢應(yīng)用信息表，確定接收控制類消息的客戶端，并主動發(fā)送控制類消息，能夠使客戶端及時獲取控制類消息。

在獲取應(yīng)用信息表之前，首先應(yīng)該建立應(yīng)用信息表。應(yīng)用信息表是根據(jù)待控制的應(yīng)用程序與客戶端之間的對應(yīng)關(guān)系提前建立的。

可選的，在獲取待發(fā)送的控制類消息，確定控制類消息對應(yīng)的至少一類客戶端之前，該方法還包括：

步驟一，接收由客戶端發(fā)送的注冊包，其中，注冊包包括：客戶端所在的地址、客戶端所在的端口及客戶端的標(biāo)識。

終端的app(客戶端)啟動時，客戶端向服務(wù)端發(fā)送注冊包，服務(wù)端接收該注冊包。注冊包中包含了客戶端的標(biāo)識，客戶端的標(biāo)識用于區(qū)分不同的種類的客戶端，例如，客戶端的標(biāo)識為客戶端的id。

步驟二，根據(jù)注冊包，在應(yīng)用信息表中寫入待控制的客戶端的信息。

在應(yīng)用信息表中，以客戶端為依據(jù)，分別標(biāo)識每種客戶端對應(yīng)的客戶端的信息。以客戶端為依據(jù)建立應(yīng)用信息表，方便根據(jù)客戶端的種類查找某種客戶端對應(yīng)的所有的客戶端的信息，查找效率高。參見圖4，客戶端a1、客戶端b1、客戶端c1及客戶端d1四個客戶端分別向服務(wù)端發(fā)送注冊包a1(ip1，port1appid1)、注冊包b1(ip2，port2appid2)、注冊包c(diǎn)1(ip1，port4appid2)及注冊包d1(ip5，port5appid2)，服務(wù)端根據(jù)四個注冊包，在應(yīng)用信息表中建立待控制的客戶端的信息，appid1對應(yīng)ip1port1，appid2對應(yīng)ip1port4，ip2port2及ip5port5。

在本發(fā)明實(shí)施例中，根據(jù)注冊包維護(hù)應(yīng)用信息表，可以增加應(yīng)用信息表的準(zhǔn)確性，為后續(xù)服務(wù)端根據(jù)應(yīng)用信息表，向?qū)?yīng)的客戶端發(fā)送控制類消息提供了技術(shù)上的支持，并且本發(fā)明實(shí)施例中的注冊包，相對于現(xiàn)有技術(shù)中的請求包，數(shù)據(jù)量更小，能夠節(jié)約數(shù)據(jù)流量。

可選的，在接收由客戶端發(fā)送的注冊包之后，該方法還包括：

向客戶端發(fā)送標(biāo)識注冊包已接收的確認(rèn)信息，其中，該確認(rèn)消息為ack消息。

服務(wù)端接收到注冊包之后，會向客戶端反饋確認(rèn)信息，用于使客戶端確定注冊包已發(fā)送成功。該確認(rèn)信息為ack(acknowledgement，確認(rèn)字符)消息。

在本發(fā)明實(shí)施例中，服務(wù)端接收到注冊包之后向客戶端返回ack消息，相比于現(xiàn)有技術(shù)中服務(wù)端接收到請求包之后向客戶端返回控制類消息，ack消息的數(shù)據(jù)量更小，能夠節(jié)約數(shù)據(jù)流量。

應(yīng)用信息表建立之后，還需要進(jìn)行維護(hù)?？蛻舳私邮沼捎脩舳税l(fā)送的標(biāo)識客戶端信息的消息，維護(hù)應(yīng)用信息表。

可選的，在獲取待發(fā)送的控制類消息，確定控制類消息對應(yīng)的至少一類客戶端之前，該方法還包括：

步驟一，接收由客戶端發(fā)送的心跳包，其中，心跳包標(biāo)識客戶端的運(yùn)行情況。

在客戶端運(yùn)行的過程中，客戶端會根據(jù)預(yù)設(shè)的時間，向服務(wù)端發(fā)送心跳包。預(yù)設(shè)的時間為符合本發(fā)明實(shí)施例的任意時間，例如三分鐘。本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸方法主要應(yīng)用于基于sip協(xié)議的udp協(xié)議(userdatagramprotocol，用戶數(shù)據(jù)報協(xié)議)網(wǎng)絡(luò)中，當(dāng)然還可以應(yīng)用到基于sip協(xié)議的tcp協(xié)議(transmissioncontrolprotocol，傳輸控制協(xié)議)網(wǎng)絡(luò)。若為udp協(xié)議網(wǎng)絡(luò)，心跳包標(biāo)識客戶端所在的ip、所在的端口及客戶端的id，這是因?yàn)樵趗dp協(xié)議網(wǎng)絡(luò)中客戶端所在的端口及客戶端所在的ip會發(fā)生改變，為了保證應(yīng)用信息表的準(zhǔn)確性，心跳包需要標(biāo)識此類信息。若為tcp協(xié)議網(wǎng)絡(luò)，心跳包標(biāo)識客戶端仍處于連接當(dāng)中，如心跳包中標(biāo)識“tick”以維護(hù)連接，心跳包標(biāo)識“tick”，數(shù)據(jù)量小，降低了信令負(fù)載。

步驟二，根據(jù)心跳包中客戶端的運(yùn)行情況，維護(hù)應(yīng)用信息表。

服務(wù)端根據(jù)心跳包維護(hù)應(yīng)用信息表。若為udp協(xié)議網(wǎng)絡(luò)，服務(wù)端根據(jù)心跳包中的信息，更新應(yīng)用信息表中的客戶端的信息，例如，在應(yīng)用信息表中標(biāo)識信息為ip1，port4，appid2的客戶端，當(dāng)服務(wù)端接收到該客戶端的心跳包標(biāo)識變更為ip3，port3，appid2時，將應(yīng)用信息表中的該客戶端的信息更新為ip3，port3，appid2。若為tcp協(xié)議網(wǎng)絡(luò)，服務(wù)端根據(jù)心跳包確定仍處于連接中的應(yīng)用，若未接收到某客戶端的心跳包，則判定該客戶端處于離線狀態(tài)，在后續(xù)確定待發(fā)送控制消息的客戶端時，便忽略該客戶端。

在本發(fā)明實(shí)施例中，根據(jù)心跳包維護(hù)應(yīng)用信息表，應(yīng)用信息表中的內(nèi)容更加準(zhǔn)確，后續(xù)根據(jù)應(yīng)用信息表查找的客戶端的信息也就更加準(zhǔn)確，控制信息發(fā)送的成功率高。

可選的，s104，包括：

步驟a，將查找到的控制類消息對應(yīng)的客戶端加入到目標(biāo)對象集合中，其中，目標(biāo)對象集合用于記錄控制類消息對應(yīng)的客戶端。

目標(biāo)對象集合初始為空集，用于記錄發(fā)送控制類消息的目標(biāo)。將查找到的控制類消息對應(yīng)的客戶端加入到目標(biāo)對象集合中，發(fā)送管理更加方便。

步驟b，根據(jù)查找到的控制類消息對應(yīng)的客戶端的信息，分別向目標(biāo)對象集合中的每個客戶端發(fā)送控制類消息。

步驟c，接收由目標(biāo)對象集合中的客戶端根據(jù)控制類消息發(fā)送的反饋信息，其中，反饋信息標(biāo)識發(fā)送反饋信息的客戶端已經(jīng)接收到控制類消息。

步驟d，將接收到的反饋信息所對應(yīng)的客戶端從目標(biāo)對象集合中清除。

步驟e，若目標(biāo)對象集合不為空，返回步驟b執(zhí)行，直至目標(biāo)對象集合為空，停止發(fā)送控制類消息；若目標(biāo)對象集合為空，停止發(fā)送控制類消息。

經(jīng)過預(yù)設(shè)時間后，判斷目標(biāo)對象集合是否為空。預(yù)設(shè)時間為符合本發(fā)明實(shí)施例的任意時間，根據(jù)網(wǎng)絡(luò)延時進(jìn)行設(shè)定。例如在網(wǎng)絡(luò)延時為20ms時，可以將預(yù)設(shè)時間設(shè)定為50ms。

在本發(fā)明實(shí)施例中，在控制類消息的傳輸過程中，服務(wù)端采用多次發(fā)送的方法完成控制類消息的傳輸，能夠應(yīng)用于udp協(xié)議的網(wǎng)絡(luò)，相比于現(xiàn)有技術(shù)中將數(shù)據(jù)包進(jìn)行緩存，傳輸速度更快。

可選的，為了防止客戶端意外掉線后，服務(wù)端無限次的向客戶端發(fā)送控制類消息，本發(fā)明實(shí)施例中還設(shè)置了發(fā)送次數(shù)閾值，發(fā)送次數(shù)閾值由運(yùn)營商自行設(shè)定(例如3次或更多，4次或更多，或5次或更多)。當(dāng)向某個客戶端發(fā)送控制類消息的次數(shù)達(dá)到發(fā)送次數(shù)閾值時，即使未收到該客戶端發(fā)送的反饋消息，服務(wù)端也會停止向該客戶端發(fā)該送控制類消息。

一種服務(wù)端與客戶端之間控制類消息的傳輸方法，應(yīng)用于基于sip協(xié)議的客戶端，包括：

接收由服務(wù)端根據(jù)應(yīng)用信息表發(fā)送的控制類消息，其中，應(yīng)用信息表標(biāo)識待控制的客戶端的信息。

當(dāng)服務(wù)端獲取控制類信息后，直接查詢應(yīng)用信息表，查找到該控制類消息對應(yīng)的客戶端，并向該控制類消息對應(yīng)的客戶端發(fā)送控制類信息?？蛻舳私邮沼煞?wù)端發(fā)送的控制類消息，無需發(fā)送請求包，相比于客戶端主動發(fā)送請求包，節(jié)約了客戶端的數(shù)據(jù)流量。

在本發(fā)明實(shí)施例中，客戶端接收由服務(wù)端發(fā)送的控制類消息，服務(wù)端主動發(fā)送控制類消息，控制類消息的傳輸更加及時。且相比于現(xiàn)有技術(shù)中客戶端主動發(fā)送請求包，節(jié)約了數(shù)據(jù)流量。

應(yīng)用信息表是根據(jù)待控制的客戶端的種類與每個客戶端的信息提前建立的。客戶端向服務(wù)端發(fā)送標(biāo)識客戶端信息的消息，以使服務(wù)端建立應(yīng)用信息表。

可選的，在接收由服務(wù)端根據(jù)應(yīng)用信息表發(fā)送的控制類消息之前，該方法還包括：

在啟動待控制的客戶端時，向服務(wù)端發(fā)送注冊包，以使服務(wù)端根據(jù)注冊包，在應(yīng)用信息表中標(biāo)識待控制的客戶端的信息，其中，注冊包包括：客戶端所在的地址、客戶端所在的端口及客戶端的標(biāo)識。

終端的客戶端啟動時，客戶端向服務(wù)端發(fā)送注冊包。例如，某個客戶端啟動時，向服務(wù)端發(fā)送注冊包(標(biāo)識ip1，port1，appid1)，服務(wù)端接收到該注冊包后，在應(yīng)用信息表中將注冊包的信息添加到對應(yīng)類型的客戶端中，即在種類appid1中添加ip1port1。

在本發(fā)明實(shí)施例中，客戶端在啟動時發(fā)送注冊包，以使服務(wù)端根據(jù)注冊包維護(hù)應(yīng)用信息表，可以增加應(yīng)用信息表的準(zhǔn)確性，為后續(xù)服務(wù)端根據(jù)應(yīng)用信息表，向?qū)?yīng)的客戶端發(fā)送控制類消息提供了技術(shù)上的支持，并且本發(fā)明實(shí)施例中的注冊包，現(xiàn)對于現(xiàn)有技術(shù)中的請求包，數(shù)據(jù)量更小，能夠節(jié)約數(shù)據(jù)流量。

可選的，在接收由服務(wù)端根據(jù)應(yīng)用信息表發(fā)送的控制類消息之前，該方法還包括：

向服務(wù)端發(fā)送心跳包，以使服務(wù)端根據(jù)心跳包維護(hù)應(yīng)用信息表，其中，心跳包標(biāo)識客戶端的運(yùn)行情況。

在客戶端運(yùn)行的過程中，客戶端會根據(jù)預(yù)設(shè)的時間，向服務(wù)端發(fā)送心跳包。該預(yù)設(shè)的時間，根據(jù)網(wǎng)絡(luò)連接類型進(jìn)行設(shè)定，例如在wifi(wirelessfidelity，無線保真)網(wǎng)絡(luò)中，設(shè)定為固定的三分鐘。若采用udp協(xié)議，心跳包標(biāo)識客戶端所處的ip、端口及客戶端的id，這是因?yàn)樵趗dp協(xié)議中，客戶端發(fā)送udp信息包(包括心跳包和注冊包)的ip及端口會經(jīng)常發(fā)生變化，若不相應(yīng)的更新應(yīng)用信息表中的客戶端的信息，會導(dǎo)致控制信息發(fā)送失敗。若為tcp協(xié)議，心跳包可僅用于維護(hù)連接，標(biāo)識客戶端仍處于連接當(dāng)中，如發(fā)送內(nèi)容為“tick”的心跳包。

在本發(fā)明實(shí)施例中，客戶端向服務(wù)端發(fā)送心跳包，以使服務(wù)端根據(jù)心跳包維護(hù)應(yīng)用信息表，應(yīng)用信息表中的內(nèi)容更加準(zhǔn)確，后續(xù)根據(jù)應(yīng)用信息表查找的目標(biāo)對象也就更加準(zhǔn)確，控制信息發(fā)送的成功率高。

參見圖5，圖5為本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)，應(yīng)用于基于sip協(xié)議的服務(wù)端的示意圖，包括：

控制類消息獲取模塊501，用于獲取待發(fā)送的控制類消息，確定控制類消息對應(yīng)的至少一類客戶端。

信息表獲取模塊502，用于獲取應(yīng)用信息表，在應(yīng)用信息表中查找到控制類消息對應(yīng)的客戶端的信息，其中，應(yīng)用信息表標(biāo)識待控制的客戶端的信息。

第一發(fā)送模塊503，用于根據(jù)查找到的控制類消息對應(yīng)的客戶端的信息，向查找到的控制類消息對應(yīng)的客戶端發(fā)送控制類消息。

在本發(fā)明實(shí)施例中，服務(wù)端通過查詢應(yīng)用信息表，確定接收控制類消息的客戶端的信息，并主動發(fā)送控制類消息，能夠使客戶端及時獲取控制類消息。

需要說明的是，本發(fā)明實(shí)施例中的系統(tǒng)是應(yīng)用上述服務(wù)端與客戶端之間控制類消息的傳輸方法的系統(tǒng)，則上述服務(wù)端與客戶端之間控制類消息的傳輸方法的的實(shí)施例均適用于該系統(tǒng)，且均能達(dá)到相同或相似的有益效果。

可選的，本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)還包括：

第二接收模塊，用于接收由客戶端發(fā)送的注冊包，其中，注冊包包括：客戶端所在的地址、客戶端所在的端口及客戶端的標(biāo)識。

第一維護(hù)模塊，用于根據(jù)注冊包，在應(yīng)用信息表中寫入待控制的客戶端的信息。

在本發(fā)明實(shí)施例中，根據(jù)注冊包維護(hù)應(yīng)用信息表，可以增加應(yīng)用信息表的準(zhǔn)確性，為后續(xù)服務(wù)端根據(jù)應(yīng)用信息表，向?qū)?yīng)的客戶端發(fā)送控制類消息提供了技術(shù)上的支持，并且本發(fā)明實(shí)施例中的注冊包，現(xiàn)對于現(xiàn)有技術(shù)中的請求包，數(shù)據(jù)量更小，能夠節(jié)約數(shù)據(jù)流量。

可選的，本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)還包括：

第三接收模塊，用于接收由客戶端發(fā)送的心跳包，其中，心跳包標(biāo)識客戶端的運(yùn)行情況。

第二維護(hù)模塊，用于根據(jù)心跳包中客戶端的運(yùn)行情況，維護(hù)應(yīng)用信息表。

在本發(fā)明實(shí)施例中，根據(jù)心跳包維護(hù)應(yīng)用信息表，應(yīng)用信息表中的內(nèi)容更加準(zhǔn)確，后續(xù)根據(jù)應(yīng)用信息表查找的客戶端的信息也就更加準(zhǔn)確，控制信息發(fā)送的成功率高。

可選的，第一發(fā)送模塊，包括：

目標(biāo)對象集合確定子模塊，用于將查找到的控制類消息對應(yīng)的至少一個客戶端加入到目標(biāo)對象集合中，其中，目標(biāo)對象集合用于記錄控制類消息對應(yīng)的客戶端。

控制類消息發(fā)送子模塊，用于根據(jù)查找到的控制類消息對應(yīng)的客戶端的信息，分別向目標(biāo)對象集合中的每個客戶端發(fā)送控制類消息。

反饋信息接收子模塊，用于接收由目標(biāo)對象集合中的客戶端根據(jù)控制類消息發(fā)送的反饋信息，其中，反饋信息標(biāo)識發(fā)送反饋信息的客戶端已經(jīng)接收到控制類消息。

目標(biāo)對象更新子模塊，用于將接收到的反饋信息所對應(yīng)的客戶端從目標(biāo)對象集合中清除。

判定模塊子模塊，用于若目標(biāo)對象集合不為空，返回控制類消息發(fā)送子模塊執(zhí)行，直至目標(biāo)對象集合為空，停止發(fā)送控制類消息；若目標(biāo)對象集合為空，停止發(fā)送控制類消息。

在本發(fā)明實(shí)施例中，在控制類消息的傳輸過程中，服務(wù)端采用多次發(fā)送的方法完成控制類消息的傳輸，能夠應(yīng)用于udp協(xié)議的網(wǎng)絡(luò)，相比于現(xiàn)有技術(shù)中將數(shù)據(jù)包進(jìn)行緩存，傳輸速度更快。

一種服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)，應(yīng)用于基于sip協(xié)議的客戶端，包括：

第一接收模塊，用于接收由服務(wù)端根據(jù)應(yīng)用信息表發(fā)送的控制類消息，其中，應(yīng)用信息表標(biāo)識待控制的客戶端的信息。

在本發(fā)明實(shí)施例中，客戶端接收由服務(wù)端發(fā)送的控制類消息，服務(wù)端主動發(fā)送控制類消息，控制類消息的傳輸更加及時。且相比于現(xiàn)有技術(shù)中客戶端主動發(fā)送請求包，節(jié)約了數(shù)據(jù)流量。

可選的，本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)還包括：

第二發(fā)送模塊，用于在啟動待控制的客戶端時，向服務(wù)端發(fā)送注冊包，以使服務(wù)端根據(jù)注冊包，在應(yīng)用信息表中標(biāo)識待控制的客戶端的信息，其中，注冊包包括：客戶端所在的地址、客戶端所在的端口及客戶端的標(biāo)識。

在本發(fā)明實(shí)施例中，客戶端在啟動時發(fā)送注冊包，以使服務(wù)端根據(jù)注冊包維護(hù)應(yīng)用信息表，可以增加應(yīng)用信息表的準(zhǔn)確性，為后續(xù)服務(wù)端根據(jù)應(yīng)用信息表，向?qū)?yīng)的客戶端發(fā)送控制類消息提供了技術(shù)上的支持，并且本發(fā)明實(shí)施例中的注冊包，現(xiàn)對于現(xiàn)有技術(shù)中的請求包，數(shù)據(jù)量更小，能夠節(jié)約數(shù)據(jù)流量。

可選的，本發(fā)明實(shí)施例的服務(wù)端與客戶端之間控制類消息的傳輸系統(tǒng)還包括：

第三發(fā)送模塊，用于向服務(wù)端發(fā)送心跳包，以使服務(wù)端根據(jù)心跳包維護(hù)應(yīng)用信息表，其中，心跳包標(biāo)識客戶端的運(yùn)行情況。

在本發(fā)明實(shí)施例中，客戶端向服務(wù)端發(fā)送心跳包，以使服務(wù)端根據(jù)心跳包維護(hù)應(yīng)用信息表，應(yīng)用信息表中的內(nèi)容更加準(zhǔn)確，后續(xù)根據(jù)應(yīng)用信息表查找的目標(biāo)對象也就更加準(zhǔn)確，控制信息發(fā)送的成功率高。

需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實(shí)體或者操作與另一個實(shí)體或操作區(qū)分開來，而不一定要求或者暗示這些實(shí)體或操作之間存在任何這種實(shí)際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。

本說明書中的各個實(shí)施例均采用相關(guān)的方式描述，各個實(shí)施例之間相同相似的部分互相參見即可，每個實(shí)施例重點(diǎn)說明的都是與其他實(shí)施例的不同之處。尤其，對于系統(tǒng)實(shí)施例而言，由于其基本相似于方法實(shí)施例，所以描述的比較簡單，相關(guān)之處參見方法實(shí)施例的部分說明即可。

以上所述僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù)范圍。凡在本發(fā)明的精神和原則之內(nèi)所作的任何修改、等同替換、改進(jìn)等，均包含在本發(fā)明的保護(hù)范圍內(nèi)。