長連接消息的通信方法及系統的制作方法
【技術領域】
[0001]本發(fā)明涉及一種通信方法及系統，特別是涉及一種長連接消息的通信方法及系統。
【背景技術】
[0002]隨著網絡與計算機科技的發(fā)展，智能家居越來越熱門。為了能實時控制設備，一般設備和服務器之間采取長連接的方式進行實時通信。移動終端通過APP，將消息發(fā)送給服務器，由服務器下發(fā)給設備。
[0003]現有技術普遍存在的問題是，移動終端和服務器之間通信采用HTTP協議，而服務器和設備之間采用一條TCP通道進行通信。由于移動終端和服務器之間的通信往往是并發(fā)的，一次通信可能會有很多個請求，但是服務器和設備之間的TCP通道只有一個，這樣就會帶來一個問題，即APP側一次發(fā)送多個請求，長連接通道返回數據的時候無法確定消息返回的先后順序，從而造成通信失敗。

【發(fā)明內容】

[0004]鑒于以上所述現有技術的缺點，本發(fā)明的目的在于提供一種長連接消息的通信方法及系統，用于解決現有技術中處理并發(fā)請求時長連接通道返回數據的時候無法確定消息返回的先后順序，從而造成通信失敗的問題。
[0005]為實現上述目的及其他相關目的，本發(fā)明提供一種長連接消息的通信方法，包括以下步驟:
[0006]采用HTTP短連接的形式與移動終端側的APP進行交互，獲取所述APP發(fā)出的請求；
[0007]為所述APP發(fā)出的請求分配消息ID ;
[0008]將已獲得消息ID的請求通過長連接通道轉發(fā)給設備處理，并接收設備返回的相應數據；
[0009]將設備返回的相應數據發(fā)送給所述APP。
[0010]優(yōu)選地，所述方法還包括:分配專用線程以處理具有消息ID的請求。
[0011 ] 優(yōu)選地，所述方法還包括:記錄具有消息ID的請求的處理狀態(tài)，為所述APP發(fā)出的請求分配消息ID時，根據前一請求的處理狀態(tài)，判斷當前請求是否可以被發(fā)送，當前請求可以被發(fā)送時為當前請求分配消息ID，否則返回阻塞。
[0012]優(yōu)選地，所述請求的處理狀態(tài)包括:請求的發(fā)送狀態(tài)和設備返回相應數據的接收狀態(tài)。
[0013]優(yōu)選地，所述方法還包括:存儲具有所述消息ID的請求對應的長連接通道信息。
[0014]基于上述目的，本發(fā)明還提供一種長連接消息的通信系統，包括:
[0015]APP連接模塊，采用HTTP短連接的形式與移動終端側的APP進行交互，獲取所述APP發(fā)出的請求；
[0016]消息控制器，為所述APP發(fā)出的請求分配消息ID ;
[0017]長連接模塊，將已獲得消息ID的請求通過長連接通道轉發(fā)給設備處理，并接收設備返回的相應數據；
[0018]所述APP連接模塊將設備返回的相應數據發(fā)送給所述APP。
[0019]優(yōu)選地，所述長連接模塊包括:同步消息線程池和同步消息狀態(tài)機；其中，所述同步消息線程池分配專用線程以處理具有所述消息ID的請求，通過所述專用線程將具有所述消息ID的請求發(fā)送給設備，接收設備返回的相應數據，并將所述返回的相應數據發(fā)送給所述APP連接模塊；所述同步消息狀態(tài)機記錄具有所述消息ID的請求的處理狀態(tài)，并儲存所述返回的相應數據。
[0020]優(yōu)選地，所述消息控制器，根據所述同步消息狀態(tài)機記錄的前一請求的處理狀態(tài)，判斷當前請求是否可以被發(fā)送，當前請求可以被發(fā)送時返回消息ID，否則返回阻塞。
[0021]優(yōu)選地，所述請求的處理狀態(tài)包括:請求的發(fā)送狀態(tài)和設備返回的相應數據的接收狀態(tài)。
[0022]優(yōu)選地，所述長連接模塊還包括連接信息存儲模塊，存儲具有所述消息ID的請求對應的長連接通道信息。
[0023]如上所述，本發(fā)明的測試服務器性能的方法及系統，具有以下有益效果:
[0024]本發(fā)明的長連接消息的通信方法及系統，通過為每個請求分配消息ID，并通過長連接通道處理具有消息ID的請求，從而可對APP側的并發(fā)請求進行調度，使得這些請求能合理的返回，消息處理過程安全可靠，解決了現有技術中通過長連接通道難以處理并發(fā)請求的問題。
【附圖說明】
[0025]圖1顯示為本發(fā)明實施例的長連接消息的通信方法的流程示意圖。
[0026]圖2顯示為本發(fā)明實施例的長連接消息的通信系統的示意圖。
[0027]圖3顯示為本發(fā)明實施例的長連接消息的通信系統的運行示意圖。
[0028]元件標號說明
[0029]1APP連接模塊
[0030]2消息控制器
[0031]3長連接模塊
[0032]301 同步消息線程池
[0033]302 同步消息狀態(tài)機
[0034]303 連接信息存儲模塊
[0035]S1 ?S4 步驟
【具體實施方式】
[0036]以下通過特定的具體實例說明本發(fā)明的實施方式，本領域技術人員可由本說明書所揭露的內容輕易地了解本發(fā)明的其他優(yōu)點與功效。本發(fā)明還可以通過另外不同的【具體實施方式】加以實施或應用，本說明書中的各項細節(jié)也可以基于不同觀點與應用，在沒有背離本發(fā)明的精神下進行各種修飾或改變。需說明的是，在不沖突的情況下，以下實施例及實施例中的特征可以相互組合。
[0037]需要說明的是，以下實施例中所提供的圖示僅以示意方式說明本發(fā)明的基本構想，遂圖式中僅顯示與本發(fā)明中有關的組件而非按照實際實施時的組件數目、形狀及尺寸繪制，其實際實施時各組件的型態(tài)、數量及比例可為一種隨意的改變，且其組件布局型態(tài)也可能更為復雜。
[0038]請參閱圖1，本實施例提供一種長連接消息的通信方法，包括:
[0039]步驟S1采用HTTP短連接的形式與移動終端側的APP進行交互，獲取所述APP發(fā)出的請求；
[0040]步驟S2為所述APP發(fā)出的請求分配消息ID ;
[0041]步驟S3將已獲得消息ID的請求通過長連接通道轉發(fā)給設備處理，并接收設備返回的相應數據；
[0042]步驟S4將設備返回的相應數據發(fā)送給所述APP。
[0043]本方法通過為每個請求分配消息ID，可對APP側的并發(fā)請求進行調度，使得這些請求能合理的返回。例如，每次有APP請求的時候，都需要到取得一個消息ID，取消息ID的過程通常是一個阻塞動作，也就是當該請求可以被發(fā)送的時候，才會返回消息ID。這樣的設計可以保證消息的有序發(fā)送和接收。
[0044]優(yōu)選地，該方法還可包括:記錄具有消息ID的請求的處理狀態(tài)，為所述APP發(fā)出的請求分配消息ID時，根據前一請求的處理狀態(tài)，判斷當前請求是否可以被發(fā)送，當前請求可以被發(fā)送時為當前請求分配消息ID，否則返回阻塞。其中，所述請求的處理狀態(tài)可以包括:請求的發(fā)送狀態(tài)和設備返回相應數據的接收狀態(tài)。
[0045]例如，新接收到的一個請求，即當前請求，需要分配消息ID時，可先查看前一請求的處理狀態(tài)，如果前一請求的處理狀態(tài)為已發(fā)送至設備，尚未接收到設備返回的數據，此時前一請求的消息處理尚未完成，可判斷當前請求還不能被發(fā)送，那么返回阻塞；當前一請求的處理狀態(tài)為已收到設備返回相應數據時，可認為前一請求的消息處理已完成，當前請求可以被發(fā)送，此時則可為當前請求分配消息ID，通過長連接通道轉發(fā)該請求。通過記錄和查看前一請求的處理狀態(tài)，可以更加合理的控制并發(fā)請求的流程。
[0046]此外，本方法，優(yōu)選地，可分配專用線程來處理具有消息ID的請求。這樣請求通過長連接通道轉發(fā)，并可按同步消息的方式返回。
[0047]優(yōu)選地，本方法還包括:存儲具有所述消息ID的請求對應的長連接通道信息。SP，存儲設備側的長連接通道信息，即設備的MAC地址與長連接通道的映射關系，也就是說，如果從某長連接通道接收到一條消息，可以根據這個映射關系知道是哪臺MAC地址的設備發(fā)出的。
[0048]本發(fā)明所述的長連接消息的通信方法的保護范圍不限于本實施例列舉的步驟執(zhí)行順序，凡是利用本發(fā)明的原理