專利名稱：手機與服務(wù)器之間的通訊方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種通訊技術(shù)，特別涉及一種手機與服務(wù)器之間的通訊方法及系統(tǒng)。
背景技術(shù)：
隨著手機移動網(wǎng)絡(luò)的迅猛發(fā)展，首當其沖的就是被譽為手機殺手锏應(yīng)用的手機音樂服務(wù)，這項應(yīng)用服務(wù)不僅拓展了手機的功能，更是極大地推動著手機硬件以及移動網(wǎng)絡(luò)的發(fā)展，讓手機不再單單只是播放手機上已經(jīng)存在的歌曲資源，而是能夠通過移動互聯(lián)網(wǎng)絡(luò)讓手機與服務(wù)器通訊成為了現(xiàn)實。通過手機音樂服務(wù)將手機與網(wǎng)絡(luò)互動的作用更加地放大和擴充，使得手機不再單單是打電話或發(fā)短信的工具，而是真正意義上的移動音樂終端， 可將更豐富的網(wǎng)絡(luò)音樂素材資源源源不斷地下載或推送到手機上。一種客戶端設(shè)備與服務(wù)端設(shè)備的通信采用如下通訊指令步驟完成交互傳輸，其可以歸納抽象描述為corm(連接)->user (用戶驗證)-> paSS(密碼安全握手)-> init (初始化數(shù)據(jù))-> list (列表)-> items (資源元素)-> download(下載)或者 play (播放)；還包括back (返回)指令和exit (退出)指令，其中back指令為返回請求前一指令的指令，其可在conn指令后任意一個指令(user, pass, init, list, items, download, play)操作后進行請求，exit指令為通知服務(wù)端設(shè)備退出客戶端設(shè)備軟件系統(tǒng)的指令，其位置順序與back指令相同；并且，list指令所請求數(shù)據(jù)為樹型結(jié)構(gòu)，若返回的數(shù)據(jù)里某葉子節(jié)點數(shù)據(jù)為列表結(jié)構(gòu)，即可重復請求list指令對葉子節(jié)點的數(shù)據(jù)進行請求。采用一種單向靜態(tài)安全登錄校驗?zāi)Ｐ?single-track static authenticationmodule, SSM)作為客戶端設(shè)備與服務(wù)器通訊過程中進行用戶驗證的方式。 參考圖1，其示出了單向靜態(tài)安全登錄校驗?zāi)Ｐ偷臅r序圖。在客戶端設(shè)備發(fā)送登錄指令 user后，一般客戶端設(shè)備還需要發(fā)送密碼校驗命令pass，這樣能夠讓服務(wù)端設(shè)備進行安全校驗。當安全校驗通過后服務(wù)端設(shè)備才能知道此客戶端設(shè)備的請求是否屬于合法的請求， 進而才可以進行后續(xù)的命令字操作。這種安全模型對于大多數(shù)客戶端設(shè)備來說足以，但是對于采用了某些計費手段的客戶端設(shè)備來說，這種方式就會有一定的局限性，這是因為只進行一次安全校驗握手，而且這種安全校驗握手是單向的行為，因而會導致某些非法程序非法侵入或是模擬指令發(fā)送以至于服務(wù)端設(shè)備對這種信息完全沒有任何的判斷能力，從而使得安全性很差。此外，在客戶端設(shè)備與服務(wù)端設(shè)備的通訊過程中使用一種客戶端多線程模型 (Mobile client multithreading module，MTM)。在該客戶端多線程模型中，在客戶端設(shè)備需要批量下載音樂素材資源或是播放歌曲的時候，采用的辦法是在某些中高端手機能夠支持的模式下，在客戶端設(shè)備采取多線程的技術(shù)同時向服務(wù)器請求素材文件數(shù)據(jù)資源，并將素材文件數(shù)據(jù)資源同步下載到客戶端設(shè)備上，其大致時序圖如圖2所示?？梢钥闯觯@種模型理論上看很不錯，幾乎可以認為同一時間段內(nèi)，數(shù)據(jù)是并發(fā)請求到服務(wù)端設(shè)備，而服務(wù)端設(shè)備也可以并發(fā)進行響應(yīng)，將數(shù)據(jù)同一時間段內(nèi)推送到客戶端設(shè)備。但是，手機硬件資源往往有限，特別是中低端手機，多線程技術(shù)一般不會被采用，如果采用那也將會極大地消耗硬件資源，使其損耗變大、壽命變短，且容易發(fā)生“死機”(宕機)現(xiàn)象；另外，即使是較高端的手機，依舊受限于手機處理器芯片的處理能力，在很小的時間片內(nèi)仍然是時間線性執(zhí)行的， 而另一個因素是雖然客戶端設(shè)備采取了多線程處理機制，但是服務(wù)端設(shè)備卻只開啟了單線程進行數(shù)據(jù)通信，那么這樣兩者結(jié)合來看處理數(shù)據(jù)資源時并不能真正達到“同時”的效果， 這樣會導致偏向單個素材資源的處理過程，而其它資源卻一直需要等待。另外，使用一種客戶端緩存模型(Mobile client cache module，CCM)來加速客戶端設(shè)備的執(zhí)行效率，因為大多數(shù)客戶端設(shè)備會采用一種手機客戶端緩存數(shù)據(jù)的技術(shù)，將歷史請求的命令得到的服務(wù)器返回數(shù)據(jù)暫存在手機內(nèi)存中，以便于在有同樣請求時可以減少對遠程服務(wù)器訪問的開銷，這項技術(shù)的關(guān)鍵之處是客戶端設(shè)備認為服務(wù)端設(shè)備在數(shù)據(jù)執(zhí)行中查找磁盤I/O所造成的開銷較大而希望盡量減少這種遠程請求，當然，這種行為只會在初始化之后進行，初始化前還是需要與服務(wù)端設(shè)備進行安全登錄校驗的，其大致流程如圖3 所示。但是，由于服務(wù)端設(shè)備不保留歷史數(shù)據(jù)以及某個客戶端設(shè)備連接的狀態(tài)，故在出現(xiàn)網(wǎng)絡(luò)故障時客戶端設(shè)備與服務(wù)器斷開連接后，客戶端設(shè)備必須通過重新連接并初始化后才能進行后續(xù)的操作，而且這些后續(xù)操作與斷開前的操作完全沒有連續(xù)性，因而使得操作效率降低，并給用戶帶來不便利性。而且，如果手機關(guān)機重啟，則暫時緩存在手機內(nèi)存中的歷史數(shù)據(jù)一并消失，客戶端設(shè)備將無法重置成上一次使用時候需要維持的任何狀態(tài)。綜上所述，在前述客戶端設(shè)備與服務(wù)端設(shè)備的通訊中，無論是基于HTTP協(xié)議的擴展還是更基礎(chǔ)的tcp/ip方式，都只是讓客戶端設(shè)備與服務(wù)端設(shè)備做簡單的握手校驗，并且在客戶端設(shè)備采取多線程技術(shù)讓手機可同時處理請求多個音樂素材資源的事務(wù)，這樣可以保障一定的數(shù)據(jù)安全性和一定的可靠性，主要提供了以下的一些技術(shù)特性(1)客戶端設(shè)備與服務(wù)端設(shè)備只在初始化之前校驗一次來源通道的合法性，然后建立長連接，之后的數(shù)據(jù)在客戶端設(shè)備傳遞到服務(wù)端設(shè)備時不再做數(shù)據(jù)加密處理；(2)客戶端設(shè)備采用多線程技術(shù)可批量處理多個任務(wù)，如批量下載音樂素材資源等；(3)通訊過程中發(fā)生網(wǎng)絡(luò)故障后可以自動嘗試重新連接，所以客戶端設(shè)備可重新進行連接來初始化或重新定位需要下載的資源文件；(4)歷史數(shù)據(jù)操作被緩存在手機的內(nèi)存中，在手機不關(guān)機重啟的情況下可以加速客戶端設(shè)備的運行效率。如上所述，可以看出上述客戶端設(shè)備與服務(wù)端設(shè)備的通訊技術(shù)存在如下幾個問題(1)由于安全登錄校驗只使用一次安全校驗握手，因而難以很好地確保通訊的安全性；(2)由于在客戶端設(shè)備使用多線程技術(shù)，導致客戶端設(shè)備損耗變大、壽命變短、速度慢，而且使得客戶端設(shè)備與服務(wù)器之間的通訊效率變低；(3)由于服務(wù)端設(shè)備不保留歷史數(shù)據(jù)以及客戶端設(shè)備連接的狀態(tài)，因而在出現(xiàn)網(wǎng)絡(luò)故障時服務(wù)端設(shè)備與客戶端設(shè)備斷開后客戶端設(shè)備必須通過重新連接并初始化后才能進行后續(xù)的操作，而且這些后續(xù)操作與斷開前的操作完全沒有連續(xù)性。(4)由于暫時緩存在手機內(nèi)存中的歷史數(shù)據(jù)在手機關(guān)機重啟后一并消失，因而客戶端設(shè)備將無法重置成上一次使用時候需要維持的任何狀態(tài)。

發(fā)明內(nèi)容
鑒于上述缺陷，本申請的一個目的是提供一種更加安全、高效的手機與服務(wù)器之間的通訊方法及系統(tǒng)，其特別適用于電信計費領(lǐng)域中的音樂客戶端軟件，可以杜絕這個領(lǐng)域中產(chǎn)生的非法請求而導致錯誤計費的現(xiàn)象。本申請的另一個目的是提供一種可以減少對手機硬件(成本)中存儲器件的依賴以使其涉及的手機覆蓋面更廣的手機與服務(wù)器之間的通訊方法及系統(tǒng)。本申請的又一個目的是提供一種充分發(fā)揮服務(wù)端設(shè)備運算能力更強大的優(yōu)勢的手機與服務(wù)器之間的通訊方法及系統(tǒng)，其能更好地利用移動網(wǎng)絡(luò)中的帶寬，更快速地完成指令數(shù)據(jù)的推送。本申請的再一個目的是提供一種在時間上無限地延續(xù)通訊命令的持續(xù)性操作的手機與服務(wù)器之間的通訊方法及系統(tǒng)。為了實現(xiàn)上述目的，本申請?zhí)岢鲆环N手機與服務(wù)器之間的通訊方法，包括如下步驟(1)服務(wù)器接收手機發(fā)送的請求一文件的數(shù)據(jù)請求；( 根據(jù)該數(shù)據(jù)請求，服務(wù)器以文件塊的形式向手機發(fā)送所請求的文件，并將發(fā)送的文件塊的位置實時記錄在緩存設(shè)備中； 以及(3)當手機與服務(wù)器的連接斷開后，服務(wù)器在接收到手機重發(fā)的數(shù)據(jù)請求時，根據(jù)該緩存設(shè)備中記錄的文件塊的位置進行后續(xù)文件塊的傳送。本申請還提出一種與手機進行通訊的系統(tǒng)，包括服務(wù)器，用于與手機進行通訊； 和緩存設(shè)備，設(shè)置于服務(wù)器內(nèi)或者獨立于服務(wù)器設(shè)置；其中，服務(wù)器在接收到手機發(fā)送的請求一文件的數(shù)據(jù)請求時，以文件塊的形式向手機發(fā)送所請求的文件，并且將發(fā)送的文件塊的位置實時記錄在緩存設(shè)備中；以及其中，服務(wù)器在與手機的連接斷開后，接收到手機重發(fā)的數(shù)據(jù)請求時，根據(jù)該緩存設(shè)備中記錄的文件塊的位置進行后續(xù)文件塊的傳送。利用本申請，可以更加安全、高效地進行計費。利用本申請，可以減少對手機硬件(成本)中存儲器件的依賴，使其涉及的手機覆
蓋面更廣。利用本申請，可以充分發(fā)揮服務(wù)端設(shè)備運算能力更強大的優(yōu)勢，服務(wù)端設(shè)備的多線程機制可讓客戶端設(shè)備和服務(wù)端設(shè)備同時建立起多個并發(fā)通信通道，進而更好地利用了移動網(wǎng)絡(luò)中的帶寬，更快速地完成指令數(shù)據(jù)的推送。利用本申請，由于服務(wù)端設(shè)備增加了緩存設(shè)備，客戶端設(shè)備請求所產(chǎn)生的任何數(shù)據(jù)均可完整保留，可在時間上無限地延續(xù)通訊命令的持續(xù)性操作，不會因為手機客戶端的斷電或關(guān)機而影響到下次運行客戶端設(shè)備軟件時歷史請求數(shù)據(jù)的正?；謴停梢栽诖嘶A(chǔ)上開發(fā)更好的人機交互系統(tǒng)，使客戶端設(shè)備在任何異常情況下都不會白白的浪費通信資源。利用本申請，通過擴展客戶端設(shè)備與服務(wù)端設(shè)備協(xié)議的模型，避免了由于設(shè)備間數(shù)據(jù)偽操作帶來的安全風險，避免了移動網(wǎng)絡(luò)資源的浪費，減低了手機硬件的損耗以及成本，增加的history命令字解決了人機交互中客戶端設(shè)備的異常而容易導致的產(chǎn)生重復而又固定不靈活的指令操作的問題。本申請包括但不限于如上優(yōu)點。當然，實施本申請的任一產(chǎn)品并不一定需要同時達到以上所述的所有優(yōu)點。


圖1示出了安全登錄校驗?zāi)Ｐ偷臅r序圖；圖2示出了客戶端多線程模型的時序圖；圖3示出了客戶端緩存模型的流程圖；圖4示例性示出了根據(jù)本申請實施例的雙向動態(tài)安全校驗?zāi)Ｐ偷臅r序圖的一實例；圖5示例性示出了根據(jù)本申請實施例的服務(wù)端多線程緩存擴展時序圖的一實例； 以及圖6示例性示出了根據(jù)本申請實施例的history命令字的關(guān)鍵時序圖的一實例。
具體實施例方式在本說明書中，除非明確說明，所提及的“客戶端設(shè)備”為音樂類手機，其能夠經(jīng)由無線網(wǎng)絡(luò)與服務(wù)器通信；所提及的“服務(wù)端設(shè)備”為為音樂類手機提供音樂下載、播放等服務(wù)的服務(wù)器。而且，在此示出的實例僅為示例性，并不旨在限制本申請的范圍。本申請對SSM、MTM和CCM三個模型進行了擴展，在服務(wù)端設(shè)備增加“歷史數(shù)據(jù)留存模型(history restore module for server，HRM) ”，并且在服務(wù)端設(shè)備一側(cè)增加了緩存設(shè)備和安全校驗設(shè)備。1、雙向動態(tài)安全校驗擴展根據(jù)一個實施例，將雙向動態(tài)安全校驗?zāi)Ｐ鸵胧謾C與服務(wù)器之間的通訊中。在該雙向動態(tài)安全校驗?zāi)Ｐ椭?，在服?wù)端設(shè)備一側(cè)設(shè)置一安全校驗設(shè)備。根據(jù)通訊系統(tǒng)的具體情況，該安全校驗設(shè)備可以結(jié)合在服務(wù)端設(shè)備內(nèi)，也可以獨立于服務(wù)端設(shè)備。這種模型可以使通訊更加安全，且尤其適用于帶有電信計費機制的音樂類手機。下面將對本實施例的雙向動態(tài)安全校驗?zāi)Ｐ瓦M行詳細描述。首先，由客戶端設(shè)備發(fā)送密碼校驗命令pass，服務(wù)端設(shè)備對從客戶端設(shè)備發(fā)送來的密碼校驗命令pass進行安全校驗，以判斷客戶端的請求是否屬于合法的請求。若密碼校驗通過，則從服務(wù)端設(shè)備發(fā)送響應(yīng)字(確認字符串)ok給客戶端，這一驗證步驟與背景技術(shù)部分描述的驗證步驟相同。然后，客戶端設(shè)備向服務(wù)端設(shè)備發(fā)送攜帶設(shè)備唯一標識 MDN(mobile directorynumber)的初始化指令init，之后根據(jù)客戶端設(shè)備的每次請求，由服務(wù)端設(shè)備一側(cè)設(shè)置的安全校驗設(shè)備隨機生成并傳遞給客戶端設(shè)備一個隨機數(shù)m和加密串 c，而在下一次的請求中客戶端設(shè)備需要將此隨機數(shù)m和加密串c以及設(shè)備唯一標識MDN傳輸給服務(wù)端設(shè)備，服務(wù)端設(shè)備一側(cè)的安全校驗設(shè)備在校驗了此次請求的合法性后隨機又生成一次隨機數(shù)m和加密串c，并且用新生成的隨機數(shù)m和加密串c替換掉安全校驗設(shè)備的內(nèi)存中原來的隨機數(shù)m和加密串C?，F(xiàn)參考圖4，以命令字init、list和items的操作舉例，描述根據(jù)本申請實施例的雙向動態(tài)安全校驗?zāi)Ｐ偷臅r序的一實例。首先，客戶端設(shè)備發(fā)送密碼校驗命令pass給服務(wù)端設(shè)備，若驗證通過，則服務(wù)端設(shè)備發(fā)送響應(yīng)字ok給客戶端設(shè)備。然后，客戶端設(shè)備發(fā)送初始化指令init給服務(wù)端設(shè)備，該初始化指令攜帶有MDN，其中“攜帶”是指該指令init后的數(shù)據(jù)段攜帶有MDN或者利用單獨的通信信道攜帶MDN。服務(wù)端設(shè)備根據(jù)該指令init對數(shù)據(jù)進行初始化，并將客戶端設(shè)備的請求發(fā)送給安全校驗設(shè)備。該安全校驗設(shè)備根據(jù)客戶端設(shè)備的請求隨機生成隨機數(shù)ml和加密串cl，并將生成的隨機數(shù)ml和加密串cl存儲在其內(nèi)存中。若初始化成功，則將攜帶生成的隨機數(shù)ml和加密串cl的響應(yīng)字welcome發(fā)送給客戶端設(shè)備。之后，客戶端設(shè)備向服務(wù)端設(shè)備發(fā)送攜帶MDN以及在上一步驟中從服務(wù)端設(shè)備接收來的隨機數(shù)ml和加密串cl的指令list。服務(wù)端設(shè)備一側(cè)的安全校驗設(shè)備將此次從客戶端設(shè)備發(fā)送來的隨機數(shù)和加密串與其內(nèi)存中已存儲的隨機數(shù)和加密串進行比較。如果二者相同，則校驗通過，服務(wù)端設(shè)備執(zhí)行指令list進行列表，且安全校驗設(shè)備再次隨機生成新的隨機數(shù)m2和密碼串c2，并將新生成的隨機數(shù)m2和密碼串c2存儲在其內(nèi)存中。將新生成的隨機數(shù)m2和密碼串c2攜帶在響應(yīng)字list song data中發(fā)送給客戶端設(shè)備。之后，根據(jù)從客戶端設(shè)備發(fā)送來的包含MDN以及隨機數(shù)m2和加密串c2的指令items，服務(wù)端設(shè)備對隨機數(shù)m2和加密串c2進行校驗，并在校驗通過的情況下，執(zhí)行指令items，并再次生成新的隨機數(shù)m3和加密串c3，將新生成的隨機數(shù)m3和加密串c3攜帶在響應(yīng)字song items data中發(fā)送給客戶端設(shè)備。在上述步驟中，若從客戶端設(shè)備發(fā)送來的隨機數(shù)和加密串與安全校驗設(shè)備的內(nèi)存中存儲的隨機數(shù)和加密串不匹配，則校驗失敗，拒絕客戶端設(shè)備接入服務(wù)端設(shè)備。該模型可以很好地杜絕常見的一種客戶端命令偽操作行為如某客戶端設(shè)備A為安裝了正常合法的客戶端軟件的終端，客戶端設(shè)備B安裝了非法的盜取了客戶端設(shè)備A所分配的用戶名和密碼的客戶端軟件，于是在利用命令user和pass進行驗證均通過的情況下，客戶端設(shè)備B在發(fā)送指令init給服務(wù)端設(shè)備的時候，由于傳遞的終端唯一標識MDN信息與服務(wù)端的不匹配，進而無法生成正確的m和c傳遞給客戶端，于是服務(wù)端設(shè)備和客戶端設(shè)備A均可以正確地判定該客戶端設(shè)備B是安裝了非法客戶端軟件的客戶端設(shè)備，從而拒絕提供服務(wù)。這樣可以更好地拒絕任何非法的客戶端請求，從而可以確保最大限度的安全性。而且，該模型還可以提供如下作用當客戶端設(shè)備A被木馬病毒感染時，由于每次通信校驗密碼是動態(tài)的，木馬無法輕易截取到校驗規(guī)則，增大了木馬破解的技術(shù)難度，由于密碼生成點的隨機性、結(jié)對性和數(shù)據(jù)的加密性，繞過這個密碼m和c過程的破解方法顯而易見是無法被服務(wù)端通過的，即使采取唯一的暴力方法破解掉，但客戶端設(shè)備A可能已經(jīng)由于資源耗盡而不能使用或者也只能在客戶端設(shè)備A上進行遠程模擬偽操作，而由于如前所述的偽操作的不可行性，并不能轉(zhuǎn)移到客戶端設(shè)備B上，則這種破解又失去了任何意義。因而，該模型可以使得通訊更為安全可靠。2、服務(wù)端多線程緩存擴展根據(jù)一個實施例，對服務(wù)端設(shè)備進行多線程緩存擴展以形成服務(wù)端多線程緩存模型。該模型主要針對于客戶端設(shè)備同時發(fā)起2個以上素材資源請求的情況。當客戶端設(shè)備僅發(fā)送1個素材資源請求時，服務(wù)端設(shè)備可以采用單線程模式。在服務(wù)端多線程緩存模型中，在服務(wù)端設(shè)備一側(cè)設(shè)置一緩存設(shè)備，根據(jù)通訊系統(tǒng)的具體情況，該緩存設(shè)備可以結(jié)合在服務(wù)端設(shè)備內(nèi)，也可以獨立于服務(wù)端設(shè)備。在下面的說明中，將以緩存設(shè)備與服務(wù)端設(shè)備彼此獨立的情況為例進行描述。下面將對根據(jù)本實施例的服務(wù)端多線程緩存模型進行詳細描述。在客戶端設(shè)備請求同時下載多個文件時，客戶端設(shè)備和服務(wù)端設(shè)備均采用多線程模式，從而可以將在客戶端設(shè)備同時下載多個文件時本來由客戶端設(shè)備完成的任務(wù)轉(zhuǎn)移到服務(wù)端設(shè)備進行；并且由于在服務(wù)端設(shè)備增加了緩存設(shè)備，因而得到的資源信息可以被緩存處理，這樣不僅能夠減少客戶端設(shè)備的硬件損耗、最大限度地利用移動網(wǎng)絡(luò)帶寬，還可讓客戶端設(shè)備在重復下載或重復批量播放歌曲的時候根據(jù)定義好的標識直接從緩存設(shè)備中取出相應(yīng)數(shù)據(jù)，減少在查找資源數(shù)據(jù)時由服務(wù)端設(shè)備磁盤I/O的低效率運作而導致的時間延遲?，F(xiàn)參照圖5，詳細描述根據(jù)本申請實施例的服務(wù)端多線程緩存的過程。首先，客戶端設(shè)備向服務(wù)端設(shè)備發(fā)送指令items請求獲得音樂信息，服務(wù)端設(shè)備根據(jù)此請求向客戶端設(shè)備發(fā)送響應(yīng)字song items info。之后，客戶端設(shè)備以多線程模式向服務(wù)端設(shè)備發(fā)送下載指令download請求下載N個對象(iteml，item 2，. . . item N)，服務(wù)端設(shè)備首先在緩存設(shè)備中尋找所請求下載的對象，若有，則直接將緩存設(shè)備中的相應(yīng)文件(filel，file 2,...file N)以多線程模式發(fā)送給客戶端設(shè)備；若無，則繼續(xù)在磁盤存儲設(shè)備中尋找，然后將相應(yīng)文件(filel,file 2，…file N)以多線程模式發(fā)送給客戶端設(shè)備。在這種擴展下，不僅通過使用緩存設(shè)備來加速請求響應(yīng)的效率，而且在客戶端設(shè)備同時發(fā)起N(N>= 2)個素材資源請求的時候，服務(wù)端設(shè)備也會同時啟動N個線程進行處理，服務(wù)端設(shè)備采用這種多線程模式將會充分地利用服務(wù)端設(shè)備高性能處理器的優(yōu)勢，即使對于緩存設(shè)備中不存在的數(shù)據(jù)，也能高效地從磁盤上讀取到相應(yīng)數(shù)據(jù)，而這時由于客戶端設(shè)備與服務(wù)端設(shè)備通信的進程內(nèi)雙方均采取多線程連接的方式，因而即使客戶端設(shè)備由于硬件的能力不足而導致“偏向”單個資源的處理，但是總體上看，可以使“偏向”效應(yīng)降低很多，這是因為服務(wù)端設(shè)備在客戶端設(shè)備處理單個資源時將會源源不端地發(fā)送其它資源的數(shù)據(jù)包，客戶端設(shè)備將不得不騰出時間片來處理這些數(shù)據(jù)包，而不是像MTM模型中雖然客戶端設(shè)備發(fā)送了多個資源請求，但是服務(wù)端設(shè)備卻只能等待單個文件處理完全完成后才能處理下一個，導致服務(wù)器時間資源成本的浪費。3、斷點續(xù)傳服務(wù)端擴展由于無線網(wǎng)絡(luò)不穩(wěn)定因素的存在(如進入信號弱覆蓋區(qū)域時)，傳統(tǒng)的MTM方式很容易在網(wǎng)絡(luò)異常時丟失有關(guān)下載到客戶端設(shè)備的數(shù)據(jù)包的情況，而不得不重新發(fā)送原始的數(shù)據(jù)請求，服務(wù)端設(shè)備則只有從頭重新進行數(shù)據(jù)包的傳輸，這不光浪費了網(wǎng)絡(luò)資源，而且還消耗了大量的重復數(shù)據(jù)包傳送的時間。針對這一情況，根據(jù)本申請的一個實施例，對服務(wù)端設(shè)備進行了斷點續(xù)傳服務(wù)的擴展。在這種擴展的斷點續(xù)傳服務(wù)中，首先，在服務(wù)端設(shè)備設(shè)定一個經(jīng)驗時間的范圍(優(yōu)選為M小時或48小時)，當在該時間范圍內(nèi)服務(wù)端設(shè)備接收到因網(wǎng)絡(luò)暫斷等原因使得客戶端設(shè)備與服務(wù)端設(shè)備斷開連接后從客戶端設(shè)備重新發(fā)送的數(shù)據(jù)請求后，服務(wù)端設(shè)備將上次傳輸中已經(jīng)記錄在服務(wù)端設(shè)備的緩存設(shè)備里的文件塊位置等信息及時響應(yīng)給客戶端，由客戶端設(shè)備識別并向服務(wù)端設(shè)備提交用于完成后續(xù)文件塊的接收工作的請求，從而服務(wù)設(shè)備端可以根據(jù)客戶端設(shè)備的此請求將后續(xù)文件塊發(fā)送給客戶端設(shè)備?，F(xiàn)將描述在本實施例中如何在數(shù)據(jù)傳輸過程中在服務(wù)端設(shè)備的緩存設(shè)備里實時記錄文件塊位置。首先，在發(fā)送初始化指令init的時候，服務(wù)端設(shè)備根據(jù)客戶端設(shè)備型號的特性推送一個適合于該客戶端設(shè)備文件系統(tǒng)能夠識別的最大文件塊大小(block size) 數(shù)據(jù)，當請求的資源文件大于這個文件塊大小的時候，傳輸時服務(wù)端設(shè)備根據(jù)這個塊大小將一個文件平均分成幾份來傳輸。而在傳輸時服務(wù)端設(shè)備將啟動一個監(jiān)控線程(monitorthread) 一直不停地去“監(jiān)視”每一個數(shù)據(jù)傳輸線程中每個文件塊的傳輸情況，例如哪個客戶端設(shè)備請求哪個資源文件，資源文件一共可分為幾塊，已經(jīng)傳輸完成了第幾個塊，該文件傳送線程是否因為網(wǎng)絡(luò)異常已經(jīng)退出等信息。從而可以將文件塊的位置實時記錄在服務(wù)端設(shè)備的緩存設(shè)備中。 其中，監(jiān)控線程的時間間隔與資源文件的大小有關(guān)，例如，可將其定義為如下面的表1所示
資源文件大小T (單位k=千字節(jié))監(jiān)控線程時間間隔 (單位S=秒)T<=300kIs300k<T<=1000k2s1000k<T<=5000k3sT>5000k5s表 14、服務(wù)端歷史數(shù)據(jù)緩存模型(HRM)如上所述，客戶端設(shè)備緩存的數(shù)據(jù)會因電力、故障等原因而丟失，因而根據(jù)本申請的一個實施例，通過在服務(wù)端設(shè)備形成服務(wù)端歷史數(shù)據(jù)緩存模型(HRM)，可以避免手機開機后“一切都需要重新來過”的問題。服務(wù)端設(shè)備的緩存設(shè)備將客戶端設(shè)備最后一次正常登錄校驗到初始化后一直到網(wǎng)絡(luò)斷開連接前的所請求的所有命令字和請求的數(shù)據(jù)包全部進行緩存，并且至少保留一設(shè)定的經(jīng)驗時間(優(yōu)選為一個月時間)，待客戶端設(shè)備恢復正常、 重新校驗并初始化完成后，客戶端設(shè)備可以很快地恢復數(shù)據(jù)到最后一次指令所形成的操作狀態(tài)中，進而讓客戶端設(shè)備更好地完成人機交互工作。在此模型中，在協(xié)議中增加命令字hist0ry，且服務(wù)端設(shè)備響應(yīng)成功的指令為 history ok，失敗則為none (表示無上次請求的歷史數(shù)據(jù))。即，客戶端設(shè)備與服務(wù)端設(shè)備的通信協(xié)議更改為如下模式(“ I ”表示“或”的關(guān)系，back、exit和list含義同背景技術(shù)中所提)conn- > user- > pass- > init— > history | - > list- > items- > download 或 play - > items- > download 或 playI - > download 或 play下面將參考圖6描述命令字history的關(guān)鍵時序的一實例。首先，客戶端設(shè)備通過發(fā)送指令user和pass進行安全校驗，在校驗通過后，客戶端設(shè)備發(fā)送攜帶MDN的初始化命令init并從服務(wù)端設(shè)備返回隨機數(shù)m和密碼串C。接著，客戶端設(shè)備發(fā)送攜帶MDN、隨機數(shù)m和密碼串c的命令字history給服務(wù)端設(shè)備，若服務(wù)端設(shè)備存在上次請求的歷史數(shù)據(jù)， 則服務(wù)端設(shè)備將表示成功的響應(yīng)字History ok發(fā)送給客戶端設(shè)備，從而使客戶端設(shè)備恢復數(shù)據(jù)到最后一次指令所形成的操作狀態(tài)，并執(zhí)行最后一次指令；若服務(wù)端設(shè)備沒有上次請求的歷史數(shù)據(jù)，則服務(wù)端設(shè)備將表示失敗的響應(yīng)字none發(fā)送給客戶端設(shè)備，從而進入正常的通訊過程。
本申請技術(shù)方案有益效果包括如下幾個方面1.可以更加安全、高效，特別適用于電信計費領(lǐng)域中的音樂客戶端軟件，可以杜絕這個領(lǐng)域中產(chǎn)生的非法請求而導致錯誤計費的現(xiàn)象；2.可以減少對手機硬件(成本)中存儲器件的依賴，使其涉及的手機覆蓋面更3.充分發(fā)揮服務(wù)端設(shè)備運算能力更強大的優(yōu)勢，服務(wù)端設(shè)備的多線程機制可讓客戶端設(shè)備和服務(wù)端設(shè)備同時建立起多個并發(fā)通信通道，進而更好地利用了移動網(wǎng)絡(luò)中的帶寬，更快速地完成指令數(shù)據(jù)的推送；4.由于服務(wù)端設(shè)備增加了緩存設(shè)備，客戶端設(shè)備請求所產(chǎn)生的任何數(shù)據(jù)均可完整保留，可在時間上無限地延續(xù)通訊命令的持續(xù)性操作，不會因為手機客戶端的斷電或關(guān)機而影響到下次運行客戶端設(shè)備軟件時歷史請求數(shù)據(jù)的正?；謴?，可以在此基礎(chǔ)上開發(fā)更好的人機交互系統(tǒng)，使客戶端設(shè)備在任何異常情況下都不會白白的浪費通信資源。通過擴展客戶端設(shè)備與服務(wù)端設(shè)備協(xié)議的模型，避免了由于設(shè)備間數(shù)據(jù)偽操作帶來的安全風險，避免了移動網(wǎng)絡(luò)資源的浪費，減低了手機硬件的損耗以及成本，增加的 history命令字解決了人機交互中客戶端設(shè)備的異常而容易導致的產(chǎn)生重復而又固定不靈活的指令操作的問題。本文記載的所有例子和條件性語言均用于教導目的，以幫助讀者理解本申請以及發(fā)明人對于現(xiàn)有技術(shù)改進所貢獻的構(gòu)思，應(yīng)將其解讀為不是對具體記載的例子和條件的限制。盡管已經(jīng)詳細描述了本申請的實施例，但應(yīng)理解在不偏離本申請的精神和范圍下可以進行各種變化、替換和變更。
權(quán)利要求
1.一種手機與服務(wù)器之間的通訊方法，包括如下步驟(1)服務(wù)器接收手機發(fā)送的請求一文件的數(shù)據(jù)請求；(2)根據(jù)該數(shù)據(jù)請求，服務(wù)器以文件塊的形式向手機發(fā)送所請求的文件，并將發(fā)送的文件塊的位置實時記錄在緩存設(shè)備中；以及(3)當手機與服務(wù)器的連接斷開后，服務(wù)器在接收到手機重發(fā)的數(shù)據(jù)請求時，根據(jù)該緩存設(shè)備中記錄的文件塊的位置進行后續(xù)文件塊的傳送。
2.根據(jù)權(quán)利要求1所述的通訊方法，還包括如下步驟將手機與服務(wù)器的連接斷開前手機最后一次正常登陸所請求的所有命令字和數(shù)據(jù)包緩存在該緩存設(shè)備中；以及當手機與服務(wù)器的連接斷開后手機重新發(fā)出連接請求時，服務(wù)器基于該緩存設(shè)備中緩存的內(nèi)容使得手機恢復到連接斷開前最后一個命令的操作狀態(tài)。
3.根據(jù)權(quán)利要求1所述的通訊方法，其中，在步驟(1)之前還包括雙向動態(tài)安全校驗步馬聚ο
4.根據(jù)權(quán)利要求3所述的通訊方法，其中，該雙向動態(tài)安全校驗步驟包括服務(wù)器在每次接收到手機的請求時，控制安全校驗設(shè)備隨機生成并在該安全校驗設(shè)備內(nèi)存儲隨機數(shù)和加密串，并將生成的隨機數(shù)和加密串傳遞給手機，通過將在手機的下一次請求中發(fā)送來的隨機數(shù)和加密串與所述安全校驗設(shè)備中存儲的隨機數(shù)和加密串進行對比來驗證手機的合法性。
5.根據(jù)權(quán)利要求1所述的通訊方法，還包括當接收到手機同時下載多個文件的請求時，服務(wù)器以多線程方式進行響應(yīng)。
6.根據(jù)權(quán)利要求1所述的通訊方法，其中，步驟( 包括服務(wù)器根據(jù)手機的特性向手機推送手機能夠識別的最大文件塊大小的數(shù)據(jù)，當請求的文件大于所述最大文件塊大小時，服務(wù)器根據(jù)所述最大文件塊大小將請求的文件平均分成多份。
7.根據(jù)權(quán)利要求1所述的通訊方法，其中，步驟⑵包括服務(wù)器以預定時間間隔監(jiān)視文件塊的傳輸情況。
8.根據(jù)權(quán)利要求7所述的通訊方法，其中，所述預定時間間隔根據(jù)請求的文件的大小而設(shè)定。
9.一種與手機進行通訊的系統(tǒng)，包括服務(wù)器，用于與手機進行通訊；和緩存設(shè)備，設(shè)置于服務(wù)器內(nèi)或者獨立于服務(wù)器設(shè)置；其中，服務(wù)器在接收到手機發(fā)送的請求一文件的數(shù)據(jù)請求時，以文件塊的形式向手機發(fā)送所請求的文件，并且將發(fā)送的文件塊的位置實時記錄在緩存設(shè)備中；以及其中，服務(wù)器在與手機的連接斷開后，接收到手機重發(fā)的數(shù)據(jù)請求時，根據(jù)該緩存設(shè)備中記錄的文件塊的位置進行后續(xù)文件塊的傳送。
10.根據(jù)權(quán)利要求9所述的系統(tǒng)，其中，該緩存設(shè)備存儲手機與服務(wù)器的連接斷開前手機最后一次正常登陸所請求的所有命令字和數(shù)據(jù)包；以及服務(wù)器在手機與服務(wù)器的連接斷開后手機發(fā)起連接請求時，基于該緩存設(shè)備中緩存的內(nèi)容使得手機恢復到連接斷開前最后一個命令的操作狀態(tài)。
11.根據(jù)權(quán)利要求9所述的系統(tǒng)，其中，該系統(tǒng)還包括安全校驗設(shè)備，其，設(shè)置于服務(wù)器內(nèi)或者獨立于服務(wù)器設(shè)置。
12.根據(jù)權(quán)利要求11所述的系統(tǒng)，其中，該安全校驗設(shè)備根據(jù)手機的每次請求隨機生成并在其內(nèi)存儲隨機數(shù)和加密串，將生成的隨機數(shù)和加密串傳遞給手機，以及通過將在手機的下一次請求中發(fā)送來的隨機數(shù)和加密串與所述安全校驗設(shè)備中存儲的隨機數(shù)和加密串進行對比來驗證手機的合法性。
13.根據(jù)權(quán)利要求9所述的系統(tǒng)，其中，服務(wù)器在手機同時下載多個文件時以多線程方式進行響應(yīng)。
14.根據(jù)權(quán)利要求9所述的系統(tǒng)，其中，服務(wù)器根據(jù)手機的特性向手機推送手機能夠識別的最大文件塊大小的數(shù)據(jù)，且當請求的文件大于所述最大文件塊大小時，服務(wù)器根據(jù)所述最大文件塊大小將請求的文件平均分成多份。
15.根據(jù)權(quán)利要求9所述的系統(tǒng)，其中，服務(wù)器以預定時間間隔監(jiān)視文件塊的傳輸情況。
16.根據(jù)權(quán)利要求15所述的系統(tǒng)，其中，所述預定時間間隔根據(jù)請求的文件的大小而設(shè)定。
全文摘要
本申請涉及一種手機與服務(wù)器之間的通訊方法及系統(tǒng)，該方法包括如下步驟(1)服務(wù)器接收手機發(fā)送的請求一文件的數(shù)據(jù)請求；(2)根據(jù)該數(shù)據(jù)請求，服務(wù)器以文件塊的形式向手機發(fā)送所請求的文件，并將發(fā)送的文件塊的位置實時記錄在緩存設(shè)備中；以及(3)當手機與服務(wù)器的連接斷開后，服務(wù)器在接收到手機重發(fā)的數(shù)據(jù)請求時，根據(jù)該緩存設(shè)備中記錄的文件塊的位置進行后續(xù)文件塊的傳送。本申請的手機與服務(wù)器之間的通訊方法及系統(tǒng)可使通信更加安全、高效。
文檔編號H04L29/08GK102158847SQ201010568330
公開日2011年8月17日 申請日期2010年12月1日 優(yōu)先權(quán)日2010年12月1日
發(fā)明者李特恩 申請人:北京迅捷英翔網(wǎng)絡(luò)科技有限公司