本發(fā)明涉及無線通信領(lǐng)域的網(wǎng)絡(luò)管理技術(shù)，尤其涉及一種通信處理方法及電子設(shè)備。

背景技術(shù)：

多個電子設(shè)備通過Web應(yīng)用進行交互，比如在智能電視以及智能手機之間基于Web應(yīng)用進行交互，通常會采用基于HTTP Polling的方式進行通信交互。但是，上述交互方法，由于不是全雙工實時交互通信，所以實時性較差；另外，最后，各類web應(yīng)用間的通信，需要根據(jù)特定需要通信方式，開發(fā)語言等實現(xiàn)相應(yīng)的通信框架，該框架不具有普適性，不可復(fù)用，在一定程度上增加了開發(fā)者的開發(fā)成本。

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

有鑒于此，本發(fā)明的目的在于提供一種通信處理方法及電子設(shè)備，能至少解決現(xiàn)有技術(shù)中存在的上述問題。

為達到上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的：

本發(fā)明實施例提供了一種通信處理方法，應(yīng)用與第一電子設(shè)備，所述方法包括：

檢測自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式為全雙工通信模式，所述第二通信模式為非全雙工通信模式；

基于自身支持的通信模式生成通信請求；

發(fā)送所述通信請求至第二電子設(shè)備，以使得所述第二電子設(shè)備基于所述通信請求，確定與所述第一電子設(shè)備建立通信連接采用的通信模式；基于所述通 信模式，與所述第一電子設(shè)備建立通信連接；

基于所述通信連接，通過網(wǎng)絡(luò)應(yīng)用與所述第二電子設(shè)備進行數(shù)據(jù)交互。

本發(fā)明實施例提供了一種通信處理方法，應(yīng)用于第二電子設(shè)備，所述方法包括：

接收到第一電子設(shè)備發(fā)來的通信請求；

基于所述通信請求，確定與所述第一電子設(shè)備建立通信連接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式為全雙工通信模式，所述第二通信模式為非全雙工通信模式；

基于所述通信模式，與所述第一電子設(shè)備建立通信連接；

基于建立的所述通信連接與所述第一電子設(shè)備進行數(shù)據(jù)交互。

本發(fā)明實施例提供了一種電子設(shè)備，包括：

檢測單元，用于檢測自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式為全雙工通信模式，所述第二通信模式為非全雙工通信模式；

信息處理單元，用于基于自身支持的通信模式生成通信請求；

通信單元，用于發(fā)送所述通信請求至第二電子設(shè)備，基于所述通信連接，通過網(wǎng)絡(luò)應(yīng)用與所述第二電子設(shè)備進行數(shù)據(jù)交互。

本發(fā)明實施例提供了一種電子設(shè)備，包括：

第二通信單元，用于接收到第一電子設(shè)備發(fā)來的通信請求；基于所述通信模式，與所述第一電子設(shè)備建立通信連接；基于建立的所述通信連接與所述第一電子設(shè)備進行數(shù)據(jù)交互；

處理單元，用于基于所述通信請求，確定與所述第一電子設(shè)備建立通信連接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式為全雙工通信模式，所述第二通信模式為非全雙工通信模式。

本發(fā)明所提供的通信處理方法及電子設(shè)備，基于確定的通信類型與第二電子設(shè)備建立通信連接，在第一電子設(shè)備端支持自適應(yīng)通信，優(yōu)先選擇最佳的高 實時全雙工通信，在不支持全雙工通信的情況下，選擇另一種通信模式進行處理。如此，能夠結(jié)合第一電子設(shè)備的情況，盡可能的保證兩個電子設(shè)備之間通信數(shù)據(jù)的實時性；另外，由于使用javascript腳本進行通信處理，因此能夠提供給應(yīng)用開發(fā)者使用javascript腳本快速接入框架，提升了復(fù)用性，并且降低了web實時應(yīng)用開發(fā)者的準入門檻。

附圖說明

圖1為本發(fā)明實施例通信處理方法流程示意圖一；

圖2為本發(fā)明實施例確定通信模式的流程示意圖；

圖3為本發(fā)明實施例通信處理方法流程示意圖二；

圖4為本發(fā)明實施例建立第一通信模式的連接流程示意圖；

圖5為本發(fā)明實施例系統(tǒng)架構(gòu)示意圖；

圖6為本發(fā)明實施例第二電子設(shè)備側(cè)組成示意圖；

圖7為本發(fā)明實施例通信組件處理交互的整體流程；

圖8為本發(fā)明實施例通信組件模塊初始化流程；

圖9為本發(fā)明實施例通信組件接收請求處理流程；

圖10為本發(fā)明實施例接收websocket數(shù)據(jù)流程；

圖11為本發(fā)明實施例通信組件處理http polling請求的流程；

圖12為本發(fā)明實施例電子設(shè)備組成結(jié)構(gòu)示意圖一；

圖13為本發(fā)明實施例電子設(shè)備組成結(jié)構(gòu)示意圖二。

具體實施方式

下面結(jié)合附圖及具體實施例對本發(fā)明再作進一步詳細的說明。

實施例一、

本發(fā)明實施例提供了一種通信處理方法，應(yīng)用與第一電子設(shè)備，如圖1所示，所述方法包括：

步驟11：檢測自身支持的通信模式；其中，所述通信模式至少包括第一通 信模式以及第二通信模式，所述第一通信模式為全雙工通信模式，所述第二通信模式為非全雙工通信模式；

步驟12：基于自身支持的通信模式生成通信請求；

步驟13：發(fā)送所述通信請求至第二電子設(shè)備，以使得所述第二電子設(shè)備基于所述通信請求，確定與所述第一電子設(shè)備建立通信連接采用的通信模式；基于所述通信模式，與所述第一電子設(shè)備建立通信連接；

步驟14：基于所述通信連接，通過網(wǎng)絡(luò)應(yīng)用與所述第二電子設(shè)備進行數(shù)據(jù)交互。

這里，所述第一電子設(shè)備可以為安裝有網(wǎng)頁瀏覽器的設(shè)備，比如，可以為智能手機、平板電腦、筆記本電腦等。

上述步驟11中所述檢測自身支持的通信模式，包括：基于自身使用的網(wǎng)頁瀏覽器，確定自身支持第一通信模式或第二通信模式；其中，所述第一通信模式至少包括基于WebSocket通信協(xié)議的通信模式，所述第二通信模式為基于HTTP協(xié)議的通信模式。

其中，所述Websocket通信協(xié)議為一種全新的雙向通信解決方案，是HTML5的一種新協(xié)議。它是一種“推”技術(shù)，滿足瀏覽器與服務(wù)器全雙工通信的需求。基于websocket通信的會在在瀏覽器和服務(wù)器之間創(chuàng)建一個單一的Socket，來完成雙向“推”與“拉”消息的功能。這種通訊方式是持續(xù)性的、有狀態(tài)的，用戶很容易就可以弄明白整個通信流程。websocket可以滿足高實時性的要求。鑒于websocket具備的高速全雙工的通信特點，它完全滿足高實時應(yīng)用的需求。從通信流程中我們很容易的總結(jié)出WebSocket通信的優(yōu)勢：它經(jīng)過一次握手即建立連接，此后互相通信不在需要傳輸攜帶冗余數(shù)據(jù)的數(shù)據(jù)頭，提高了效率并且節(jié)省了網(wǎng)絡(luò)資源；另一點是它能保證客戶端與服務(wù)器是全雙工異步通信，從而大大的提高了通信的實時性。

所述基于自身支持的通信模式生成通信請求，可以包括：若支持第一通信模式，則基于預(yù)設(shè)的JavaScript腳本生成包含有第一關(guān)鍵字的通信請求；若僅支持第二通信模式，則基于預(yù)設(shè)的JavaScript腳本生成包括有第二關(guān)鍵字的通 信請求。

其中，所述JavaScript腳本可以表征用于提供統(tǒng)一的對外接口、以及智能檢測通信方式的腳本；比如，可以通過JavaScript腳本建立通信連接用于發(fā)送數(shù)據(jù)、接收數(shù)據(jù)或者關(guān)閉通信連接，或者，還可以通過JavaScript腳本提供心跳機制。所述JavaScript腳本，可以如下所示：

<scriptsrc＝"sockets.js"></script>

<script>

var socket＝io('http://服務(wù)器IP地址:端口/命名空間')；

socket.on('connect',function(){})；//與服務(wù)器建立連接

socket.emit('msg',{some:'data'})；//給服務(wù)器發(fā)送數(shù)據(jù)

socket.on('disconnect',function(){})；//與服務(wù)器斷開連接

</script>。

需要注意的是，只要第一電子設(shè)備安裝的瀏覽器能夠支持第一通信模式就會優(yōu)選采用第一通信模式進行后續(xù)的通信流程處理；只有當?shù)谝浑娮釉O(shè)備僅支持第二通信模式的時候，才會基于第二通信模式完成后續(xù)的處理。如此，就能夠在第一電子設(shè)備端支持自適應(yīng)通信，優(yōu)先選擇最佳的高實時全雙工通信，在不支持全雙工通信的情況下，選擇另一種通信模式進行處理，從而能夠結(jié)合第一電子設(shè)備的實際情況盡可能的保證通信數(shù)據(jù)的實時性與安全性。

下面，結(jié)合圖2對本實施例提供的第一電子設(shè)備開啟客戶端web應(yīng)用，使用集成javascript腳本與第二電子設(shè)備建立連接的，以及基于所述通信連接，通過網(wǎng)絡(luò)應(yīng)用與所述第二電子設(shè)備進行數(shù)據(jù)交互的操作，進行說明：

開啟第一電子設(shè)備之后，通過腳本檢查瀏覽器是否支持第一通信模式即websocket協(xié)議，如果支持websocket協(xié)議，與安裝有框架服務(wù)器的第二電子設(shè)備建立websocket連接；建立websocket連接后，通過javascript腳本的心跳機制進行連接探測，當心跳探測到異常連接，則啟動websocket重連；在保證連接正常的情況下客戶端應(yīng)用即可與所述第二電子設(shè)備的框架服務(wù)器進行數(shù)據(jù)傳輸；

如果腳本檢測到瀏覽器不支持websocket協(xié)議，則建立基于第二通信模式連接通信，本解決方案中支持XHR-Polling與Jsonp-Polling兩種HTTP輪詢協(xié)議?？蛻舳藈eb應(yīng)用與框架服務(wù)器建立HTTP Polling連接后，腳本可以動態(tài)調(diào)整輪詢的時間，盡可能的提高消息交互的實時性。

上述簡單的示例展示了web應(yīng)用與框架服務(wù)器建立連接，發(fā)送消息，斷開連接整個過程。由腳本自行檢測瀏覽器支持的最佳通信方式，websocket通信方式優(yōu)先選擇。

可見，通過采用上述方案，基于確定的通信類型與第二電子設(shè)備建立通信連接，在第一電子設(shè)備端支持自適應(yīng)通信，優(yōu)先選擇最佳的高實時全雙工通信，在不支持全雙工通信的情況下，選擇另一種通信模式進行處理。如此，能夠結(jié)合第一電子設(shè)備的情況，盡可能的保證兩個電子設(shè)備之間通信數(shù)據(jù)的實時性；另外，由于使用javascript腳本進行通信處理，因此能夠提供給應(yīng)用開發(fā)者使用javascript腳本快速接入框架，提升了復(fù)用性，并且降低了web實時應(yīng)用開發(fā)者的準入門檻。

實施例二、

本發(fā)明實施例提供了一種通信處理方法，應(yīng)用于第二電子設(shè)備，如圖3所示，所述方法包括：

步驟31：接收到第一電子設(shè)備發(fā)來的通信請求；

步驟32：基于所述通信請求，確定與所述第一電子設(shè)備建立通信連接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式為全雙工通信模式，所述第二通信模式為非全雙工通信模式；

步驟33：基于所述通信模式，與所述第一電子設(shè)備建立通信連接；

步驟34：基于建立的所述通信連接與所述第一電子設(shè)備進行數(shù)據(jù)交互。

這里，所述第一電子設(shè)備可以為安裝有網(wǎng)頁瀏覽器的設(shè)備，比如，可以為智能手機、平板電腦、筆記本電腦等。第二電子設(shè)備則可以為智能電視。

所述基于所述通信請求，確定與所述第一電子設(shè)備建立通信連接采用的通 信模式，包括：基于預(yù)設(shè)的JavaScript腳本，對接收到的通信請求進行解析；若解析得到的通信請求為包含有第一關(guān)鍵字的通信請求，則確定通信模式為第一通信模式；否則，確定通信模式為第二通信模式；其中，所述第一通信模式至少包括基于WebSocket通信協(xié)議的通信模式，所述第二通信模式為基于HTTP協(xié)議的通信模式。

所述Websocket通信協(xié)議為一種全新的雙向通信解決方案，是HTML5的一種新協(xié)議。它是一種“推”技術(shù)，滿足瀏覽器與服務(wù)器全雙工通信的需求。基于websocket通信的會在在瀏覽器和服務(wù)器之間創(chuàng)建一個單一的Socket，來完成雙向“推”與“拉”消息的功能。這種通訊方式是持續(xù)性的、有狀態(tài)的，用戶很容易就可以弄明白整個通信流程。websocket可以滿足高實時性的要求。鑒于websocket具備的高速全雙工的通信特點，它完全滿足高實時應(yīng)用的需求。從通信流程中我們很容易的總結(jié)出WebSocket通信的優(yōu)勢：它經(jīng)過一次握手即建立連接，此后互相通信不在需要傳輸攜帶冗余數(shù)據(jù)的數(shù)據(jù)頭，提高了效率并且節(jié)省了網(wǎng)絡(luò)資源；另一點是它能保證客戶端與服務(wù)器是全雙工異步通信，從而大大的提高了通信的實時性。

所述基于自身支持的通信模式生成通信請求，可以包括：若支持第一通信模式，則基于預(yù)設(shè)的JavaScript腳本生成包含有第一關(guān)鍵字的通信請求；若僅支持第二通信模式，則基于預(yù)設(shè)的JavaScript腳本生成包括有第二關(guān)鍵字的通信請求。

上述第一通信模式中全雙工通信模式，比如websocket方式的交互模式可以如圖4所示：客戶端通過添加有第一關(guān)鍵字的通信請求至服務(wù)器側(cè)；所述服務(wù)器側(cè)根據(jù)接收到的具備第一關(guān)鍵字的通信請求確定接收到了進行Websocket通信的請求，若同意，則向客戶端返回同意建立Websocket通信的響應(yīng)信息；服務(wù)器以及客戶端雙方基于建立的通信連接進行數(shù)據(jù)傳輸。其中，所述第一關(guān)鍵字可以為在所述通信請求的包頭中包含的upgrade等信息。另外，所述第二關(guān)鍵字可以為xhrPolling、jsonPolling等。

本實施例中對第一電子設(shè)備的個數(shù)不做限定，比如，圖5所示提供的應(yīng)用 場景，所述第二電子設(shè)備52安裝有具備通信框架的通信單元?？蚣懿渴鹪谥悄茈娨暥耍?wù)器端的應(yīng)用也部署在智能電視上。通過無線網(wǎng)絡(luò)及有線網(wǎng)絡(luò)使電視與智能手機511、平板電腦512、便攜電腦513等第一電子設(shè)備處于同一網(wǎng)絡(luò)中。

優(yōu)選地，本實施例還包括：所述第二電子設(shè)備在自身的服務(wù)框架側(cè)進行注冊，生成應(yīng)用信息列表；與所述第一電子設(shè)備建立通信連接后，將所述應(yīng)用信息列表發(fā)送給所述第一電子設(shè)備，以使得所述第一電子設(shè)備基于所述應(yīng)用信息列表進行應(yīng)用選擇并進行綁定，并基于綁定的應(yīng)用進行后續(xù)數(shù)據(jù)交互。具體可以包括：

第二電子設(shè)備開啟后，框架會隨之啟動，初始化服務(wù)框架上的Web服務(wù)器，啟動循環(huán)監(jiān)聽程序，等待第一電子設(shè)備的連接；

第二電子設(shè)備的應(yīng)用也隨之啟動，默認狀況需要其自動向Web服務(wù)器發(fā)送連接請求，并將應(yīng)用的信息注冊在Web服務(wù)器；

當?shù)谝浑娮釉O(shè)備中安裝的應(yīng)用通過網(wǎng)絡(luò)向智能電視發(fā)送連接請求后，服務(wù)框架將已注冊的應(yīng)用信息列表發(fā)送給第一電子設(shè)備；第一電子設(shè)備選擇需要綁定的應(yīng)用，向第二電子設(shè)備提交綁定請求；

第二電子設(shè)備的框架服務(wù)器識別綁定請求將第二電子設(shè)備的應(yīng)用與第一電子設(shè)備端的應(yīng)用進行綁定，之后雙方就可以在任意時間異步的發(fā)送消息通信。

本實施例中默認狀況設(shè)置服務(wù)器端應(yīng)用是一對多通信，即一個服務(wù)器端應(yīng)用可以綁定多個客戶端應(yīng)用，意味著框架必須提供廣播機制。

總體功能框圖如圖6所示，框架的通信組件使用C++語言進行開發(fā)，C++語言接近匯編語言，高效。編譯生成的目標代碼質(zhì)量高，程序執(zhí)行效率高。記錄應(yīng)用相關(guān)信息的數(shù)據(jù)表存儲在系統(tǒng)內(nèi)存中，減少使用外置數(shù)據(jù)所產(chǎn)生的交互及系統(tǒng)資源的占用。以上特性保證框架可在嵌入式環(huán)境中部署且保證跨平臺的移植性。框架的前端javascript腳本(圖6中JS腳本)支持web應(yīng)用快速接入框架服務(wù)器。

通信組件主要需要滿足的需求是：從網(wǎng)絡(luò)中獲取原始套接字請求；提供 Web服務(wù)器供應(yīng)用連接；提供對WebSocket通信協(xié)議解析的模塊；提供最終消息解析分發(fā)的功能。

Javascript腳本滿足需求：是客戶端應(yīng)用通過簡單接口與通信組件連接，并且能自行選擇最佳通信方式保證客戶端應(yīng)用于通信組件交互的實時性與準確性。

(1)底層I/O處理模塊：框架利用它提供的內(nèi)置HTTP包裝器很方便的實現(xiàn)了框架底層的HTTP服務(wù)器，用來監(jiān)聽處理原始網(wǎng)絡(luò)套接字。為通信過程中各個流程注冊事件，事件沒有觸發(fā)前，該模塊一直處于循環(huán)監(jiān)聽狀態(tài)。當該模塊監(jiān)聽的事件發(fā)生時，事件注冊的回調(diào)函數(shù)就會被調(diào)用，處理相應(yīng)的事務(wù)。本模塊I/O處理基于epoll機制，它為處理大量用戶的并發(fā)請求提供了保障。

(2)底層輕量級web服務(wù)器：為應(yīng)用程序指定相應(yīng)的連接端口，為socket對象提供以下的事件：connect、data、end、timeout、drain、error、close等。本模塊對這些事件設(shè)置了特定的回調(diào)函數(shù)來處理特定的業(yè)務(wù)流程。這些回調(diào)函數(shù)都是異步執(zhí)行的，當函數(shù)注冊完成后，都是各自等待相應(yīng)事件去觸發(fā)，相互間并無影響。其提供非堵塞的I/O模型，使我們開發(fā)的框架伸縮性更好。

(3)中間層通信模塊：封裝了一套統(tǒng)一的且方便使用的API接口供客戶端Web應(yīng)用調(diào)用，它可以保證客戶端開發(fā)者不需要關(guān)心底層的傳輸協(xié)議，僅僅使用javascript腳本通過簡單的API就可以實現(xiàn)與框架服務(wù)器的連接及異步的發(fā)送和接收消息；它可以幫助客戶端開發(fā)人員實現(xiàn)跨瀏覽器、跨平臺的實時應(yīng)用。重點支持WebSocket的通信方式，所以本模塊能保證Web應(yīng)用與框架服務(wù)器可以高速全雙工的通信，它完全可以滿足高實時應(yīng)用的需求。

(4)上層消息解析器：解析由網(wǎng)絡(luò)發(fā)送過來的數(shù)據(jù)請求。本層定義了一套Web API，以滿足特定應(yīng)用的通信要求。服務(wù)器端應(yīng)用及客戶端應(yīng)用通過本層可以互相綁定，發(fā)送消息，由消息解析器解析后處理轉(zhuǎn)發(fā)，以達到相互通信目的。

框架通信組件實現(xiàn)整個web應(yīng)用間交互的通信流程如圖7所示：

首先是啟動web服務(wù)器；設(shè)置相應(yīng)的監(jiān)聽端口，啟動Web服務(wù)器監(jiān)聽，這 是服務(wù)器的網(wǎng)絡(luò)入口地址；區(qū)別應(yīng)用是服務(wù)器端應(yīng)用還是遠程客戶端應(yīng)用，比如，可以通過使用命名空間定義應(yīng)用類型。接著中間通信處理模塊進行模塊的初始化工作，這點非常重要，因為在這個過程中框架需要大量的注冊各種事件，通過回調(diào)函數(shù)達到異步實時通信的目的，它還要在這個過程中啟動我們的輕量級Web服務(wù)器，等待用戶連接。

此后用戶通過網(wǎng)絡(luò)連接服務(wù)器，服務(wù)器為用戶分配標識ID，保存設(shè)備名稱，設(shè)置最大連接數(shù)等。最大連接數(shù)實質(zhì)應(yīng)用希望最多綁定的應(yīng)用數(shù)，超過了這個綁定數(shù)，框架需要保證新的綁定請求失?。环?wù)器端應(yīng)用與客戶端應(yīng)用進行綁定；

其次框架在與應(yīng)用連接后，通過協(xié)議解析模塊進行網(wǎng)絡(luò)協(xié)議解析。此后框架底層將接收的消息遞交給消息解析器，由消息解析器經(jīng)過推送應(yīng)用信息、綁定服務(wù)器端應(yīng)用與遠程客戶端應(yīng)用進行消息處理與轉(zhuǎn)發(fā)，即達到了應(yīng)用間的相互連接通信。

最后，框架還將處理應(yīng)用關(guān)閉的情況。當用戶主動遞交關(guān)閉消息請求關(guān)閉時，框架會將其關(guān)閉消息通知給與其連接應(yīng)用，然后斷開連接，清除連接信息。當用戶因為意外情況(網(wǎng)絡(luò)終端)或者強制關(guān)閉時，框架將啟用心跳，超時重連等機制，以保證在設(shè)定的時間內(nèi)用戶重新連接即可保持連接，超時后即當作用戶關(guān)閉，斷開連接，清除連接信息，然后關(guān)閉服務(wù)器。

本通信服務(wù)框架在嵌入式系統(tǒng)中運行時是以一種插件的形式運行在第二電子設(shè)備的系統(tǒng)上，所以當?shù)诙娮釉O(shè)備啟動時，框架組件也隨之啟動。為了保證框架正常運行，此時需要很多的初始化工作，通信組件的初始化序列如圖8所示：

步驟801：框架會創(chuàng)建管理器(Manager)的實例，用于統(tǒng)籌處理所有來自應(yīng)用的請求信息。

步驟802：Manager負責(zé)為不同的類型的應(yīng)用創(chuàng)建命名空間，應(yīng)用的類型需要事先定義好，如果不使用任何自定義的命名空間，框架選擇創(chuàng)建默認命名空間，此時所有發(fā)送請求的應(yīng)用都被視作是同一類型的應(yīng)用。

步驟803：然后框架需要創(chuàng)建并啟動一個Web服務(wù)器，這一點至關(guān)重要，服務(wù)器端應(yīng)用或者移動客戶端應(yīng)用都需要通過網(wǎng)絡(luò)來連接這個服務(wù)器，才能達到最終應(yīng)用間互聯(lián)通信的目的。此服務(wù)器在系統(tǒng)運行期間一直處于工作狀態(tài)，當無信息交互時，它時刻處在監(jiān)聽狀態(tài)(監(jiān)聽固定的端口號，根據(jù)需求自主設(shè)定)。

步驟804：框架使用的是采用事件驅(qū)動模型和非阻塞I/0模型。服務(wù)器啟動時會監(jiān)聽“error”、“request”、“upgrade”及“close”事件，這些事件與客戶端封裝的javascript腳本所使用一致，服務(wù)器為這些事件注冊了回調(diào)函數(shù)，當有事件發(fā)生時才會執(zhí)行某些特定的操作，并且這些回調(diào)函數(shù)都是異步執(zhí)行的。如此設(shè)計不但會提高資源的利用率，而且也改善了性能。

應(yīng)用監(jiān)聽到connect事件成功響應(yīng)后，表示該應(yīng)用與服務(wù)框架連接成功。

應(yīng)用于框架連接成功后即可通過emit方法向框架發(fā)送特定的事件和數(shù)據(jù)。

應(yīng)用監(jiān)聽到disconnect事件的響應(yīng)后，標識該應(yīng)用于服務(wù)框架斷開連接。

通信組件接收請求的處理流程如圖9所示：

互連通信模塊初始化時，服務(wù)框架已經(jīng)注冊了各類事件，當有相應(yīng)的請求從客戶端應(yīng)用發(fā)來時，服務(wù)框架的Manager類提供一個統(tǒng)一的消息處理接口handleRequest，基于websocket協(xié)議的請求是由此接口進入。

如果檢測出請求是基于websocket協(xié)議的合法請求，框架會創(chuàng)建websocket類的實例，并且創(chuàng)建Websocket庫的對象，與客戶端應(yīng)用握手建立連接，之后保持該會話連接，之后服務(wù)器端與客戶端即可正常通信，此時的互相發(fā)送的數(shù)據(jù)并不包含HTTP協(xié)議頭等冗余信息，是純數(shù)據(jù)。

服務(wù)器端與客戶端應(yīng)用發(fā)送的數(shù)據(jù)由框架中的原生Socket實例接收，Socket實例注冊監(jiān)聽接收數(shù)據(jù)的事件，當接收到數(shù)據(jù)時，回調(diào)函數(shù)作出響應(yīng)，可將數(shù)據(jù)進一步遞交至上層消息解析模塊。

如果是自定義類型的應(yīng)用發(fā)來的請求，會產(chǎn)生不同類型的Socket實例，承擔相應(yīng)不同類型應(yīng)用的數(shù)據(jù)傳輸任務(wù)。

在websocket協(xié)議上，數(shù)據(jù)是通過一系列的幀來傳輸?shù)摹３鲇诎踩目紤]， 為了避免使網(wǎng)絡(luò)中間設(shè)施(如攔截代理)出現(xiàn)混亂等原因，客戶端必須標記所有發(fā)往服務(wù)器的數(shù)據(jù)幀。

通信組件處理websocket數(shù)據(jù)的整體流程如圖10所示：

當服務(wù)器接收到一個沒有標記的數(shù)據(jù)幀時，服務(wù)器會認為本次通話是非法的，它會立即關(guān)閉連接，并向客戶端反饋一個含有狀態(tài)碼1002(協(xié)議錯誤)的關(guān)閉幀信息。

服務(wù)器則不能不標記它發(fā)給客戶端的任何幀。如果客戶端檢測收到標記了的幀，則必須關(guān)閉連接并可能發(fā)送1002狀態(tài)碼(協(xié)議錯誤)的關(guān)閉幀。

在上述握手連接成功后，在客戶端沒有收到關(guān)閉數(shù)據(jù)幀之前，客戶端或服務(wù)器可以在任何時間向?qū)Ψ桨l(fā)送數(shù)據(jù)幀。當互聯(lián)通信模塊接收到基于websocket協(xié)議的數(shù)據(jù)時，將會根據(jù)具體的幀協(xié)議對收到的數(shù)據(jù)幀做解析處理。

原生Socket從網(wǎng)絡(luò)中獲得原始數(shù)據(jù)幀，將其交給websocket數(shù)據(jù)解析類處理。

首先解析數(shù)據(jù)幀中Opcode比特位，它定義了數(shù)據(jù)幀的類型，包括：后續(xù)幀，文本幀，二進制幀，控制幀以及關(guān)閉連接幀等等，如果接收到未知的操作碼，則接收端必須關(guān)閉websocket連接。不同的幀類型，解析其攜帶的Payload數(shù)據(jù)方式也不一樣的，如收到的數(shù)據(jù)幀為文本幀，它的有效載荷數(shù)據(jù)是UTF-8編碼的文本數(shù)據(jù)，則將其交予Parse類處理。

其次要檢測數(shù)據(jù)幀中Mask比特位是否被標記為1，以此來確保這個數(shù)據(jù)幀是從客戶端發(fā)往框架的Web服務(wù)器的。

將數(shù)據(jù)幀解析后封裝為上層可使用的數(shù)據(jù)結(jié)構(gòu)，然后通過websocket實例注冊的消息監(jiān)聽回調(diào)函數(shù)，通知并將封裝好的數(shù)據(jù)傳遞給websocket實例。

websocket實例通過Manager確認該數(shù)據(jù)是由哪種應(yīng)用發(fā)送的，然后根據(jù)不同類型的Socket實例交給上層消息解析模塊處理。其中，所述確定數(shù)據(jù)由哪種應(yīng)用發(fā)送可以為：判斷所述數(shù)據(jù)是由客戶端應(yīng)用或者是由服務(wù)器端應(yīng)用發(fā)送的數(shù)據(jù)。

框架通信組件處理HTTP Polling的流程如圖11所示：

Manager管理器接受HTTP Poling請求，通過XHRPOlling對象獲取完整的請求報文。

解析請求報文，分別獲取請求報文頭和消息內(nèi)容。

根據(jù)報文頭和消息內(nèi)容發(fā)送一個響應(yīng)給客戶端應(yīng)用，告知客戶端應(yīng)用是服務(wù)器接受請求是否正常。

將獲取的消息體交給Parse類解析，將解析封裝好的消息體交給Transport類進一步處理。

Transport類中onMessage()方法進一步處理消息，檢查消息類型是否有效及根據(jù)具體消息類型(心跳，關(guān)閉，確認及數(shù)據(jù)請求等)進入不同的處理邏輯。

模塊更深入詳細的實現(xiàn)機制在這里不做贅述，從上述模塊初始化完成的工作，及web應(yīng)用端如何使用javascript腳本快速接入服務(wù)框架可是得出以下結(jié)論：

首先，框架提供給應(yīng)用開發(fā)者使用javascript腳本快速接入框架，一定程度上降低了web實時應(yīng)用開發(fā)者的準入門檻。

其次，框架實現(xiàn)了基于websocket協(xié)議的通信方式，意味著開發(fā)者可以使用目前很火的html5技術(shù)快速研發(fā)更多優(yōu)質(zhì)的web應(yīng)用，在提高用戶體驗的同時促進了交互式應(yīng)用的發(fā)展。另一方面也保證了在瀏覽器不支持websocket協(xié)議的情況下，前端JS腳本能自行選擇http polling方式保證消息通信的準確性，且通過動態(tài)調(diào)節(jié)輪詢時間提高應(yīng)用交互的實時性。

可見，通過采用上述方案，就基于確定的通信類型與第二電子設(shè)備建立通信連接，在第一電子設(shè)備端支持自適應(yīng)通信，優(yōu)先選擇最佳的高實時全雙工通信，在不支持全雙工通信的情況下，選擇另一種通信模式進行處理。如此，能夠結(jié)合第一電子設(shè)備的情況，盡可能的保證兩個電子設(shè)備之間通信數(shù)據(jù)的實時性；另外，由于使用javascript腳本進行通信處理，因此能夠提供給應(yīng)用開發(fā)者使用javascript腳本快速接入框架，提升了復(fù)用性，并且降低了web實時應(yīng)用開發(fā)者的準入門檻。

實施例三、

本發(fā)明實施例提供了一種電子設(shè)備，如圖12所示，包括：

檢測單元1201，用于檢測自身支持的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式為全雙工通信模式，所述第二通信模式為非全雙工通信模式；

信息處理單元1202，用于基于自身支持的通信模式生成通信請求；

通信單元1203，用于發(fā)送所述通信請求至第二電子設(shè)備，基于所述通信連接，通過網(wǎng)絡(luò)應(yīng)用與所述第二電子設(shè)備進行數(shù)據(jù)交互。

上述檢測單元1201，用于基于自身使用的網(wǎng)頁瀏覽器，確定自身支持第一通信模式或第二通信模式；其中，所述第一通信模式至少包括基于WebSocket通信協(xié)議的通信模式，所述第二通信模式為基于HTTP協(xié)議的通信模式。

其中，所述Websocket通信協(xié)議為一種全新的雙向通信解決方案，是HTML5的一種新協(xié)議。它是一種“推”技術(shù)，滿足瀏覽器與服務(wù)器全雙工通信的需求?；趙ebsocket通信的會在在瀏覽器和服務(wù)器之間創(chuàng)建一個單一的Socket，來完成雙向“推”與“拉”消息的功能。這種通訊方式是持續(xù)性的、有狀態(tài)的，用戶很容易就可以弄明白整個通信流程。websocket可以滿足高實時性的要求。鑒于websocket具備的高速全雙工的通信特點，它完全滿足高實時應(yīng)用的需求。從通信流程中我們很容易的總結(jié)出WebSocket通信的優(yōu)勢：它經(jīng)過一次握手即建立連接，此后互相通信不在需要傳輸攜帶冗余數(shù)據(jù)的數(shù)據(jù)頭，提高了效率并且節(jié)省了網(wǎng)絡(luò)資源；另一點是它能保證客戶端與服務(wù)器是全雙工異步通信，從而大大的提高了通信的實時性。

所述信息處理單元1202，用于若支持第一通信模式，則基于預(yù)設(shè)的JavaScript腳本生成包含有第一關(guān)鍵字的通信請求；若僅支持第二通信模式，則基于預(yù)設(shè)的JavaScript腳本生成包括有第二關(guān)鍵字的通信請求。

需要注意的是，只要第一電子設(shè)備安裝的瀏覽器能夠支持第一通信模式就會優(yōu)選采用第一通信模式進行后續(xù)的通信流程處理；只有當?shù)谝浑娮釉O(shè)備僅支持第二通信模式的時候，才會基于第二通信模式完成后續(xù)的處理。如此，就能夠在第一電子設(shè)備端支持自適應(yīng)通信，優(yōu)先選擇最佳的高實時全雙工通信，在 不支持全雙工通信的情況下，選擇另一種通信模式進行處理，從而能夠結(jié)合第一電子設(shè)備的實際情況盡可能的保證通信數(shù)據(jù)的實時性與安全性。

可見，通過采用上述方案，就基于確定的通信類型與第二電子設(shè)備建立通信連接，在第一電子設(shè)備端支持自適應(yīng)通信，優(yōu)先選擇最佳的高實時全雙工通信，在不支持全雙工通信的情況下，選擇另一種通信模式進行處理。如此，能夠結(jié)合第一電子設(shè)備的情況，盡可能的保證兩個電子設(shè)備之間通信數(shù)據(jù)的實時性；另外，由于使用javascript腳本進行通信處理，因此能夠提供給應(yīng)用開發(fā)者使用javascript腳本快速接入框架，提升了復(fù)用性，并且降低了web實時應(yīng)用開發(fā)者的準入門檻。

實施例四、

本發(fā)明實施例提供了一種電子設(shè)備，如圖13所示，包括：

第二通信單元1301，用于接收到第一電子設(shè)備發(fā)來的通信請求；基于所述通信模式，與所述第一電子設(shè)備建立通信連接；基于建立的所述通信連接與所述第一電子設(shè)備進行數(shù)據(jù)交互；

處理單元1302，用于基于所述通信請求，確定與所述第一電子設(shè)備建立通信連接采用的通信模式；其中，所述通信模式至少包括第一通信模式以及第二通信模式，所述第一通信模式為全雙工通信模式，所述第二通信模式為非全雙工通信模式。

這里，所述第一電子設(shè)備可以為安裝有網(wǎng)頁瀏覽器的設(shè)備，比如，可以為智能手機、平板電腦、筆記本電腦等。第二電子設(shè)備則可以為智能電視。

所述處理單元1302，用于基于預(yù)設(shè)的JavaScript腳本，對接收到的通信請求進行解析；若解析得到的通信請求為包含有第一關(guān)鍵字的通信請求，則確定通信模式為第一通信模式；否則，確定通信模式為第二通信模式；其中，所述第一通信模式至少包括基于WebSocket通信協(xié)議的通信模式，所述第二通信模式為基于HTTP協(xié)議的通信模式。

上述第一通信模式中全雙工通信模式，比如websocket方式的交互模式可 以如圖4所示：客戶端通過添加有第一關(guān)鍵字的通信請求至服務(wù)器側(cè)；所述服務(wù)器側(cè)根據(jù)接收到的具備第一關(guān)鍵字的通信請求確定接收到了進行Websocket通信的請求，若同意，則向客戶端返回同意建立Websocket通信的響應(yīng)信息；服務(wù)器以及客戶端雙方基于建立的通信連接進行數(shù)據(jù)傳輸。

本實施例中對第一電子設(shè)備的個數(shù)不做限定，比如，圖5所示提供的應(yīng)用場景，所述第二電子設(shè)備52安裝有具備通信框架的通信單元?？蚣懿渴鹪谥悄茈娨暥?，服務(wù)器端的應(yīng)用也部署在智能電視上。通過無線網(wǎng)絡(luò)及有線網(wǎng)絡(luò)使電視與智能手機511、平板電腦512、便攜電腦513等第一電子設(shè)備處于同一網(wǎng)絡(luò)中。

優(yōu)選地，所述處理單元1302，還用于在自身的服務(wù)框架側(cè)進行注冊，生成應(yīng)用信息列表；與所述第一電子設(shè)備建立通信連接后，通過第二通信單元1301將所述應(yīng)用信息列表發(fā)送給所述第一電子設(shè)備，基于綁定的應(yīng)用進行后續(xù)數(shù)據(jù)交互。

具體可以包括：

第二電子設(shè)備開啟后，框架會隨之啟動，初始化服務(wù)框架上的Web服務(wù)器，啟動循環(huán)監(jiān)聽程序，等待第一電子設(shè)備的連接；

第二電子設(shè)備的應(yīng)用也隨之啟動，默認狀況需要其自動向Web服務(wù)器發(fā)送連接請求，并將應(yīng)用的信息注冊在Web服務(wù)器；

當?shù)谝浑娮釉O(shè)備中安裝的應(yīng)用通過網(wǎng)絡(luò)向智能電視發(fā)送連接請求后，服務(wù)框架將已注冊的應(yīng)用信息列表發(fā)送給第一電子設(shè)備；第一電子設(shè)備選擇需要綁定的應(yīng)用，向第二電子設(shè)備提交綁定請求；

第二電子設(shè)備的框架服務(wù)器識別綁定請求將第二電子設(shè)備的應(yīng)用與第一電子設(shè)備端的應(yīng)用進行綁定，之后雙方就可以在任意時間異步的發(fā)送消息通信。

本實施例中默認狀況設(shè)置服務(wù)器端應(yīng)用是一對多通信，即一個服務(wù)器端應(yīng)用可以綁定多個客戶端應(yīng)用，意味著框架必須提供廣播機制。

第二電子設(shè)備的處理單元的總體功能框圖如圖6所示，框架的通信組件使用C++語言進行開發(fā)，C++語言接近匯編語言，高效。編譯生成的目標代碼質(zhì) 量高，程序執(zhí)行效率高。記錄應(yīng)用相關(guān)信息的數(shù)據(jù)表存儲在系統(tǒng)內(nèi)存中，減少使用外置數(shù)據(jù)所產(chǎn)生的交互及系統(tǒng)資源的占用。以上特性保證框架可在嵌入式環(huán)境中部署且保證跨平臺的移植性。處理單元的框架的前端javascript腳本(圖6中JS腳本)支持web應(yīng)用快速接入框架服務(wù)器。

通信組件主要需要滿足的需求是：從網(wǎng)絡(luò)中獲取原始套接字請求；提供Web服務(wù)器供應(yīng)用連接；提供對WebSocket通信協(xié)議解析的模塊；提供最終消息解析分發(fā)的功能。Javascript腳本滿足需求：是客戶端應(yīng)用通過簡單接口與通信組件連接，并且能自行選擇最佳通信方式保證客戶端應(yīng)用于通信組件交互的實時性與準確性。

處理單元中還包括有通信組件；其中，所述通信組件中包括有：

底層I/O處理模塊，基于異步和事件驅(qū)動模式的I/O庫。用于提供的內(nèi)置HTTP包裝器很方便的實現(xiàn)了框架底層的HTTP服務(wù)器，用來監(jiān)聽處理原始網(wǎng)絡(luò)套接字。為通信過程中各個流程注冊事件，事件沒有觸發(fā)前，該模塊一直處于循環(huán)監(jiān)聽狀態(tài)。當該模塊監(jiān)聽的事件發(fā)生時，事件注冊的回調(diào)函數(shù)就會被調(diào)用，處理相應(yīng)的事務(wù)。本模塊I/O處理基于epoll機制，它為處理大量用戶的并發(fā)請求提供了保障。

底層輕量級web服務(wù)器，用于為應(yīng)用程序指定相應(yīng)的連接端口，為socket對象提供以下的事件：connect、data、end、timeout、drain、error、close等。本模塊對這些事件設(shè)置了特定的回調(diào)函數(shù)來處理特定的業(yè)務(wù)流程。這些回調(diào)函數(shù)都是異步執(zhí)行的，當函數(shù)注冊完成后，都是各自等待相應(yīng)事件去觸發(fā)，相互間并無影響。其提供非堵塞的I/O模型，使我們開發(fā)的框架伸縮性更好。

中間層通信模塊，用于封裝統(tǒng)一的且方便使用的API接口供第一電子設(shè)備側(cè)的客戶端Web應(yīng)用調(diào)用。它可以保證客戶端開發(fā)者不需要關(guān)心底層的傳輸協(xié)議，僅僅使用javascript腳本通過簡單的API就可以實現(xiàn)與框架服務(wù)器的連接及異步的發(fā)送和接收消息；它可以幫助客戶端開發(fā)人員實現(xiàn)跨瀏覽器、跨平臺的實時應(yīng)用。重點支持WebSocket的通信方式，所以本模塊能保證Web應(yīng)用與框架服務(wù)器可以高速全雙工的通信，它完全可以滿足高實時應(yīng)用的需求。

上層消息解析器，用于解析由網(wǎng)絡(luò)發(fā)送過來的數(shù)據(jù)請求。本層定義了一套Web API，以滿足特定應(yīng)用的通信要求。服務(wù)器端應(yīng)用及客戶端應(yīng)用通過本層可以互相綁定，發(fā)送消息，由消息解析器解析后處理轉(zhuǎn)發(fā)，以達到相互通信目的。

框架通信組件實現(xiàn)整個web應(yīng)用間交互的通信流程如圖7所示：首先是啟動web服務(wù)器，設(shè)置相應(yīng)的監(jiān)聽端口，這是服務(wù)器的網(wǎng)絡(luò)入口地址。為了框架可以區(qū)別應(yīng)用是服務(wù)器端應(yīng)用還是遠程客戶端應(yīng)用使用命名空間定義應(yīng)用類型。接著中間通信處理模塊進行模塊的初始化工作，這點非常重要，因為在這個過程中框架需要大量的注冊各種事件，通過回調(diào)函數(shù)達到異步實時通信的目的，它還要在這個過程中啟動我們的輕量級Web服務(wù)器，等待用戶連接。此后用戶通過網(wǎng)絡(luò)連接服務(wù)器，服務(wù)器為用戶分配標識ID，保存設(shè)備名稱，設(shè)置最大連接數(shù)等。最大連接數(shù)實質(zhì)應(yīng)用希望最多綁定的應(yīng)用數(shù)，超過了這個綁定數(shù)，框架需要保證新的綁定請求失敗。

其次框架在與應(yīng)用連接后，通過協(xié)議解析模塊處理消息。此后框架底層將接收的消息遞交給消息解析器，由消息解析器經(jīng)過推送應(yīng)用信息、綁定服務(wù)器端應(yīng)用與遠程客戶端應(yīng)用、消息處理與轉(zhuǎn)發(fā)，即達到了應(yīng)用間的相互連接通信。

最后，框架還將處理應(yīng)用關(guān)閉的情況。當用戶主動遞交關(guān)閉消息請求關(guān)閉時，框架會將其關(guān)閉消息通知給與其連接應(yīng)用，然后斷開連接，清除連接信息。當用戶因為意外情況(網(wǎng)絡(luò)終端)或者強制關(guān)閉時，框架將啟用心跳，超時重連等機制，以保證在設(shè)定的時間內(nèi)用戶重新連接即可保持連接，超時后即當作用戶關(guān)閉，斷開連接，清除連接信息。

可見，通過采用上述方案，就基于確定的通信類型與第二電子設(shè)備建立通信連接，在第一電子設(shè)備端支持自適應(yīng)通信，優(yōu)先選擇最佳的高實時全雙工通信，在不支持全雙工通信的情況下，選擇另一種通信模式進行處理。如此，能夠結(jié)合第一電子設(shè)備的情況，盡可能的保證兩個電子設(shè)備之間通信數(shù)據(jù)的實時性；另外，由于使用javascript腳本進行通信處理，因此能夠提供給應(yīng)用開發(fā)者使用javascript腳本快速接入框架，提升了復(fù)用性，并且降低了web實時應(yīng)用開 發(fā)者的準入門檻。

本發(fā)明實施例所述集成的模塊如果以軟件功能模塊的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，也可以存儲在一個計算機可讀取存儲介質(zhì)中。基于這樣的理解，本發(fā)明實施例的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機設(shè)備(可以是個人計算機、服務(wù)器、或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分。而前述的存儲介質(zhì)包括：U盤、移動硬盤、只讀存儲器(ROM，Read-Only Memory)、隨機存取存儲器(RAM，Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。這樣，本發(fā)明實施例不限制于任何特定的硬件和軟件結(jié)合。

以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。