一種數(shù)據(jù)包的處理方法、裝置及服務器的制造方法
【技術領域】
[0001]本發(fā)明涉及通信技術領域，尤其涉及一種數(shù)據(jù)包的處理方法、裝置及服務器。
【背景技術】
[0002]XMPP (Extensible Messaging and Presence Protocol)是一種以可擴展標記語言(XML)為基礎的開放式即時通訊協(xié)議，是經(jīng)互聯(lián)網(wǎng)工程工作小組(IETF)通過的互聯(lián)網(wǎng)標準。XMPP規(guī)定了近實時的、可擴展的即時消息(Instant Messaging)傳輸標準，憑借其巨大的靈活性和開放性在即時通訊市場上占有了很大的份額。許多互聯(lián)網(wǎng)和計算機行業(yè)巨頭均采用XMPP協(xié)議實現(xiàn)其即時消息通訊服務。
[0003]目前在全世界范圍，許多正在運轉的大規(guī)模即時消息(頂)系統(tǒng)，都是按XMPP協(xié)議或按XMPP協(xié)議框架進行改造和擴展類似的協(xié)議。
[0004]由于XMPP協(xié)議是從早期的jabber協(xié)議發(fā)展而來，主要針對的環(huán)境是互聯(lián)網(wǎng)和個人電腦(PC)環(huán)境。因此在移動互聯(lián)網(wǎng)和移動終端的環(huán)境里面會存在以下問題:
[0005]1.采用XML描述消息，消息體比較大，空間浪費嚴重，不適合需要省流量省電的移動互聯(lián)網(wǎng)環(huán)境。
[0006]2.直接采用XML流方式解析，在數(shù)據(jù)包比較大或通信環(huán)境比較惡劣的情況下，出現(xiàn)通信故障時，需要重新解析，效率低下，并且沒有嚴格的消息確認和重發(fā)機制，有可能會出現(xiàn)包丟失或重復。
[0007]3.XMPP協(xié)議擴展麻煩，需要嚴格定義，不適合業(yè)務快速變化。

【發(fā)明內(nèi)容】

[0008]為了解決上述技術問題，本發(fā)明公開了一種數(shù)據(jù)包的處理方法、裝置及服務器，解決了現(xiàn)有技術中消息體較大，解析效率低下，沒有嚴格的消息確認和重發(fā)機制，容易出現(xiàn)丟包或重復，不適合業(yè)務快速化的問題。
[0009]依據(jù)本發(fā)明的一個方面，提供了一種數(shù)據(jù)包的處理方法，包括:
[0010]生成待發(fā)送的基于可擴展消息與存在協(xié)議XMPP消息數(shù)據(jù)，所述XMPP消息數(shù)據(jù)包括消息頭和消息體；
[0011]將所述消息頭進行自定義封裝，得到封裝后的消息頭；
[0012]將所述消息體轉換為符合預設協(xié)議格式的消息體；
[0013]將所述封裝后的消息頭和符合預設協(xié)議格式的消息體進行封裝，得到新的消息包；
[0014]發(fā)送所述新的消息包。
[0015]其中，將所述消息頭進行自定義封裝，得到封裝后的消息頭的步驟包括:
[0016]將所述消息按照自定義協(xié)議頭格式封裝，所述自定義協(xié)議頭包括:消息長度、消息序號、消息類型標志、消息通信質量標志以及壓縮標志。
[0017]其中，所述消息長度為消息長度字段與消息序號字段、消息包類型字段、消息通信質量控制字段、消息壓縮標志以及XMPP消息體的UTF-8字節(jié)流的長度之和；
[0018]所述消息序號，用于消息配對使用，對發(fā)送的消息包必須經(jīng)過序號應答回復；
[0019]所述消息包類型主要包括請求包和響應包,所述請求包和所述響應包之間的所述消息序號必須配對；
[0020]所述壓縮標志用于區(qū)分所述消息體是否采用了壓縮方式；
[0021]所述消息通信質量標志，用于區(qū)別消息發(fā)送的不同響應級別；其中所述不同響應級別包括:允許收不到或丟失、確認收到以及支持消息回執(zhí)。
[0022]其中，將所述消息體轉換為符合預設協(xié)議格式的消息體的步驟包括:
[0023]將所述消息體轉換為符合UTF-8協(xié)議格式的消息體。
[0024]其中，所述發(fā)送所述新的消息包的步驟為:
[0025]獲取所述新的消息包的響應級別；
[0026]依據(jù)所述響應級別發(fā)送所述新的消息包。
[0027]其中，所述新的消息包的響應級別為確認收到的類型時，所述方法還包括:
[0028]檢測預設時間內(nèi)是否接收到第一客戶端的確認包；
[0029]若未收到所述確認包，則再次發(fā)送所述新的消息包。
[0030]其中，所述新的消息包的響應級別為支持消息回執(zhí)的類型時，所述方法還包括:
[0031]向第一客戶端發(fā)送確認包；
[0032]轉發(fā)所述消息包至第二客戶端；
[0033]檢測是否接收到第二客戶端的確認包；
[0034]若接收到第二客戶端的確認包，則向第一客戶端發(fā)送回執(zhí)消息；
[0035]若未接收到第二客戶端的確認包，則向第二客戶端再次發(fā)送所述新的消息包。
[0036]依據(jù)本發(fā)明的另一個方面，提供了一種數(shù)據(jù)包的處理裝置，包括:
[0037]生成模塊，用于生成待發(fā)送的基于可擴展消息與存在協(xié)議XMPP消息數(shù)據(jù)，所述XMPP消息數(shù)據(jù)包括消息頭和消息體；
[0038]第一封裝模塊，用于將所述消息頭進行自定義封裝，得到封裝后的消息頭；
[0039]轉換模塊，用于將所述消息體轉換為符合預設協(xié)議格式的消息體；
[0040]第二封裝模塊，用于將所述封裝后的消息頭和符合預設協(xié)議格式的消息體進行封裝，得到新的消息包；
[0041]第一發(fā)送模塊，用于發(fā)送所述新的消息包。
[0042]其中，所述第一封裝模塊具體用于將所述消息按照自定義協(xié)議頭格式封裝，所述自定義協(xié)議頭包括:消息長度、消息序號、消息類型標志、消息通信質量標志以及壓縮標志。
[0043]其中，所述消息長度為消息長度字段與消息序號字段、消息包類型字段、消息通信質量控制字段、消息壓縮標志以及XMPP消息體的UTF-8字節(jié)流的長度之和；
[0044]所述消息序號，用于消息配對使用，對發(fā)送的消息包必須經(jīng)過序號應答回復；
[0045]所述消息包類型的主要包括請求包和響應包,所述請求包和所述響應包之間的所述消息序號必須配對；
[0046]所述壓縮標志用于區(qū)分所述消息體沒有采用壓縮方和所述消息體采用了 zip壓縮方式；
[0047]所述消息通信質量標志，用于區(qū)別消息發(fā)送的不同響應級別；
[0048]其中，所述不同響應級別包括:允許收不到或丟失、確認收到以及支持消息回執(zhí)。
[0049]其中，所述轉換模塊具體用于將所述消息體轉換為符合UTF-8協(xié)議格式的消息體。
[0050]其中，所述第一發(fā)送模塊還包括:
[0051]第一獲取單元，用于獲取所述消息包的響應級別；
[0052]第一發(fā)送單元，用于依據(jù)所述響應級別發(fā)送所述新的消息包。
[0053]其中，所述消息包的響應級別為確認收到的類型時，所述第一發(fā)送模塊，還包括:
[0054]第一檢測單元，用于檢測預設時間內(nèi)是否接收到第一客戶端的確認包；
[0055]若未收到來自客戶端的確認包，則第一發(fā)送單元再次發(fā)送所述新的消息包。
[0056]其中，所述消息包的響應級別為支持消息回執(zhí)的類型時，所述第一發(fā)送模塊，還包括:
[0057]第二發(fā)送單元，用于向第一客戶端發(fā)送確認包；
[0058]第三發(fā)送單元，用于轉發(fā)消息包至第二客戶端；
[0059]第二檢測單元，用于檢測是否接收到第二客戶端的確認包；
[0060]第四發(fā)送單元，用于若接收到第二客戶端的確認包，則向第一客戶端發(fā)送回執(zhí)信息；
[0061]未接收到第二客戶端的確認包，則第三發(fā)送單元再次向所述第二客戶端轉發(fā)所述新的消息包。
[0062]依據(jù)本發(fā)明的另一個方面，提供了一種服務器，包括以上所述的數(shù)據(jù)包的處理裝置。
[0063]本發(fā)明的有益效果是:
[0064]本發(fā)明的技術方案，采用數(shù)據(jù)協(xié)議包的通信方式，用協(xié)議頭封裝XMPP數(shù)據(jù)包，通過協(xié)議頭長度字段保障數(shù)據(jù)的完整性，并且定義了不同類型數(shù)據(jù)包的通信質量，保障了不同類型數(shù)據(jù)包的通信質量模式，并且將原始包體轉換為更加有利于采用壓縮算法進行壓縮的格式。
【附圖說明】
[0065]圖