周東仿，孟 寧

(中國科學技術(shù)大學軟件學院，江蘇蘇州215123)

0 引言

網(wǎng)絡和智能設備發(fā)展的最終目標都是為人類服務的，給人類提供便捷、高效、舒適、安全的生活環(huán)境，如何將個人或家庭所擁有的各種智能設備互聯(lián)互通而不管其分散在何處成為一個新的研究課題。在將來會出現(xiàn)各種智能設備，用戶希望不論在何時何地都能隨心所欲地獲取屬于自己的設備資源信息，正是為了滿足這個社會需求，個人域互聯(lián)網(wǎng)絡應運而生，這是一種新的網(wǎng)絡概念。它以個人或家庭為單位，把個人或家庭所擁有的、分布在不同地理位置的各種智能電子設備接入互聯(lián)網(wǎng)后，通過自發(fā)現(xiàn)、自組織、互連在一起形成一種新網(wǎng)絡，在這種新網(wǎng)絡中各種智能設備之間可以互相通信，基于設備自動發(fā)現(xiàn)機制的應用能夠進一步實現(xiàn)資源共享和協(xié)同服務。這樣它既能夠提供多樣化的服務又能提供個性化的服務，如安防監(jiān)控、遠程辦公、設備管理、媒體資源傳輸與共享等。個人域互聯(lián)網(wǎng)絡的提出將改變當今信息時代普通用戶的家庭生活方式和工作方式，以個人域互聯(lián)網(wǎng)絡為基本單元的一個有序化網(wǎng)絡體系結(jié)構(gòu)的誕生，為眼下正在如火如荼發(fā)展的物聯(lián)網(wǎng)技術(shù)、云計算技術(shù)注入了生機和活力。為充分而有效的利用數(shù)字設備，融合和互通已是大勢所趨。

1 概述

1.1 動態(tài)組網(wǎng)技術(shù)現(xiàn)狀及不足

為滿足現(xiàn)代消費者對各種智能電子設備管理與使用的新需求，為充分利用家庭、企業(yè)、個人現(xiàn)有的數(shù)字終端設備，打破這些設備所處于的“信息孤島”狀態(tài)，實現(xiàn)各種智能設備之間的自動發(fā)現(xiàn)與關(guān)聯(lián)，從而可以進行資源共享和協(xié)同服務，國內(nèi)外都做了大量的研究，并且形成了多種標準，如:閃聯(lián)標準IGRS技術(shù)，Java智能網(wǎng)絡框架Jini技術(shù)，開放服務網(wǎng)關(guān)OSGI技術(shù)，家庭音視頻交互技術(shù)HAVi，數(shù)字生活網(wǎng)聯(lián)盟DLNA技術(shù)，其中典型的為DLNA技術(shù)和IGRS技術(shù)，DLNA的全稱是 DIGITAL LIVING NETW0RK ALLIANCE，它以UpnP作為DLNA的基礎(chǔ)協(xié)議，它的設計目的是為了解決個人電腦、消費電器、移動電子設備的互聯(lián)互通，即在家庭內(nèi)建立一個集中管理個人電腦、家電和移動電子設備的互操作性網(wǎng)絡。事實上，DLNA并不是創(chuàng)造性技術(shù)，而是形成一種大家都可以遵守的規(guī)范［1-2］。由于它是以UPnP協(xié)議作為基礎(chǔ)協(xié)議，需要相應系統(tǒng)及路由器的支持，且一般僅能在局域網(wǎng)內(nèi)工作，缺乏考慮同外網(wǎng)的互聯(lián)互通。另外還存在如下問題:

組網(wǎng)過程復雜，實現(xiàn)起來繁瑣，設備發(fā)現(xiàn)效率較低;只考慮了設備之間的資源共享，沒有采用任何安全機制;只是簡單地對智能設備進行了分類，所覆蓋的設備范圍較小［3］;設備以監(jiān)聽組播地址的方式實現(xiàn)其他設備在線狀態(tài)的發(fā)現(xiàn)及服務的發(fā)現(xiàn)，該監(jiān)聽方式具有一定的不確定性和不穩(wěn)定性。

閃聯(lián)標準IGRS也同樣存在上述這些問題，此外，在閃聯(lián)標準中缺少對網(wǎng)絡的管理機制進行完善和詳細的描述，各節(jié)點處于相同地位，因此協(xié)同工作困難［4］。DLNA、IGRS在家庭局域網(wǎng)內(nèi)進行設備間的資源共享是沒有問題的，但是在移動互聯(lián)網(wǎng)的背景下，這些設備并不是固定在家庭或者某個區(qū)域內(nèi)部，因此像DLNA、IGRS等技術(shù)都無法滿足移動互聯(lián)網(wǎng)條件下的用戶需求。

事實上，已有一些研究者認識到了各種標準在發(fā)現(xiàn)機制上存在的一些不足，并提出了一些改進方法，如文獻［5］中提出了對閃聯(lián)協(xié)議的改進，但仍然是通過復雜的算法來查找宣告設備，整個協(xié)議實現(xiàn)起來較復雜、較繁瑣，一般用戶操作起來也較困難;如文獻［6-7］提出了NAT穿透技術(shù)，發(fā)現(xiàn)效率也不高;文獻［8］提出了借助網(wǎng)關(guān)技術(shù)，還有文獻［9］中，通過設計非常復雜繁瑣的服務器來實現(xiàn)非常有限的資源共享功能，花費的代價較大，實現(xiàn)的效率較低，更無法處理大量的并發(fā)數(shù)據(jù)連接，缺少通用性。

1.2 ADDP機制的提出

上述所列出的設備發(fā)現(xiàn)機制一般僅能實現(xiàn)局域網(wǎng)內(nèi)的發(fā)現(xiàn)，在互聯(lián)網(wǎng)中的發(fā)現(xiàn)實現(xiàn)起來較復雜、較困難，而ADDP機制的出現(xiàn)可以解決移動互聯(lián)網(wǎng)條件下的設備發(fā)現(xiàn)問題。ADDP即Auto Device Detecting Protocol設備自發(fā)現(xiàn)協(xié)議，是一種應用層的新協(xié)議，它基于TCP/IP協(xié)議族，通信機制采用功能強大的WebSocket技術(shù)，使用現(xiàn)有幾種非常成熟的網(wǎng)絡規(guī)范，通過實時自動更新DeviceList(設備列表)，在互聯(lián)網(wǎng)范圍內(nèi)實現(xiàn)了智能設備之間的自動發(fā)現(xiàn)、自動管理、自動提供服務的自治網(wǎng)絡架構(gòu)。通過運用ADDP機制，智能設備可以實時動態(tài)地加入某個網(wǎng)絡，并向所在網(wǎng)絡廣播本設備信息及提供相應的服務，實現(xiàn)了自動感知網(wǎng)絡上的其他設備和服務。即使設備是“零配置”也可自動發(fā)現(xiàn)各種不同類型的設備，提高了不同智能設備之間的互操作能力和協(xié)同性。ADDP機制屏蔽了各種設備、網(wǎng)絡之間的差異，也屏蔽了它們之間的接口，它將通信消息統(tǒng)一封裝為JSON格式，充分利用WebSocket全雙工、實時性的通信特點［10］，通過建立WebSocket長連接的方式，實現(xiàn)智能設備之間的實時互聯(lián)互通。它與底層互聯(lián)機制無關(guān)，可支持有線、無線、藍牙、Zigbee等多種連接方式，從而能夠廣泛支持不同網(wǎng)絡、不同設備之間的互聯(lián)互通，提高了其通用性。它可作為其他應用系統(tǒng)實現(xiàn)的底層，可承載圖片、音視頻信息及高速數(shù)據(jù)傳輸?shù)榷喾N應用。它具有發(fā)現(xiàn)范圍廣、發(fā)現(xiàn)效率高、安全穩(wěn)定、簡單方便可行等特點，ADDP發(fā)展的終極目標是家庭或個人域互聯(lián)網(wǎng)絡的高度智能一體化。

2 技術(shù)原理

2.1 WebSocket技術(shù)

個人域互聯(lián)網(wǎng)絡要求接入的設備能夠?qū)崟r動態(tài)發(fā)現(xiàn)和組網(wǎng)，所以采用WebSocket技術(shù)進行通信。WebSocket是整個ADDP機制運行的基礎(chǔ)，沒有WebSocket長連接的建立，整個ADDP機制便無法實現(xiàn)。

WebSocket協(xié)議是一種基于一個TCP連接的、可以實現(xiàn)全雙工通信的新協(xié)議，即不僅客戶端能向服務端發(fā)送數(shù)據(jù)，而且服務端也可以主動推送數(shù)據(jù)到客戶端。其通信過程是首先由客戶端發(fā)送請求頭信息到服務端，然后服務端對請求頭信息進行判斷是否是WebSocket請求，如果是，則會發(fā)送一次握手信息到客戶端。僅需這一次握手，客戶端和服務端之間就“開辟”了一條快速通道，兩者之間就可以互相傳送數(shù)據(jù)了。與HTTP協(xié)議相比，它有更加輕量級的頭信息，把HTTP協(xié)議給輕量化了;減少了不少交互信息和網(wǎng)絡吞吐量，節(jié)省了帶寬，提高了通信效率，基本解決了Web實時性的問題。人們設計它的目的也是在客戶端和服務端之間提供一種有狀態(tài)的、雙向的、持續(xù)的通信方式，也即在它們之間形成長連接。這項技術(shù)實現(xiàn)了以前無法通過Web實現(xiàn)的高實時性、高交互性的網(wǎng)絡應用［11-12］。

2.2 基于WebSocket的ADDP機制架構(gòu)

設備自發(fā)現(xiàn)機制基本組成部分包括設備端和賬戶服務器端，WebSocket使得客戶端與服務端的通信變得實時高效、節(jié)省帶寬又不浪費過多的數(shù)據(jù)流量。設備自發(fā)現(xiàn)系統(tǒng)的框架結(jié)構(gòu)如圖1所示。

圖1 設備自發(fā)現(xiàn)系統(tǒng)的框架結(jié)構(gòu)

ADDP客戶端與賬戶服務器建立WebSocket連接成功后，從設備配置信息庫中提取賬號、設備編號、IP地址等設備信息，其工作分為兩種情況:

(1)與賬戶服務器之間網(wǎng)絡通信良好時，ADDP客戶端與賬戶服務器直接通信，通過WebSocket維持連接，由賬戶服務器提供設備配置信息庫;(2)與賬戶服務器無法通信時，ADDP設備向局域網(wǎng)內(nèi)發(fā)送廣播，獲取設備列表和設備信息，在設備本地建立設備配置信息庫。

其中，圖1中虛線上半部分表示互聯(lián)網(wǎng)中的設備發(fā)現(xiàn)情況，虛線下半部分表示局域網(wǎng)中的設備發(fā)現(xiàn)情況，實線箭頭部分是情況 (1)，虛線箭頭部分代表情況 (2)。

2.3 客戶端

客戶端的功能主要包括發(fā)起與賬戶服務器的連接請求，連接成功后進行設備信息注冊，發(fā)送 DeviceID(設備編號)、DeviceName(設備名稱)、DeviceType(設備類型)、AccountID(賬戶編號)和AccountPasswd(密碼)到賬戶服務器上注冊設備;將這些信息記錄到設備配置信息庫中，設備便能夠從相應的數(shù)據(jù)源獲得所有能訪問到的設備列表。每當設備列表發(fā)生變化時，通過WebSocket自動推送回客戶端，進行實時的更新設備列表信息。當賬戶服務器因為網(wǎng)絡連接問題或賬戶服務器自身問題無法提供設備自動發(fā)現(xiàn)服務時，設備會自動進入ADDP機制客戶端的局域網(wǎng)模式，局域網(wǎng)模式類似UPnP的簡單服務發(fā)現(xiàn)協(xié)議SSDP［13］，ADDP機制客戶端會向局域網(wǎng)廣播自身信息，局域網(wǎng)內(nèi)同一賬號的設備會響應自身的設備信息，以達到局域網(wǎng)內(nèi)設備自動發(fā)現(xiàn)的目的。ADDP機制客戶端具體工作流程描述如圖2所示，其中AS為AccountServer(賬戶服務器)的縮寫，WS為 WebSocket的縮寫，DL為 DeviceList(設備列表)的縮寫，下同。

圖2 ADDP客戶端工作流程

ADDP機制客戶端啟動后，首先發(fā)起與AS建立WS連接請求，一旦建立成功便發(fā)送當前設備信息到AS;AS收到設備信息后，便把當前設備信息寫入到數(shù)據(jù)庫中，從而實現(xiàn)更新服務器DL;然后把最新的DL推送給與AS建立WS連接的其他設備上，從而保證每個設備端獲取到的DL都是最新的。當ADDP機制客戶端與AS建立連接失敗時，將轉(zhuǎn)入ADDP機制局域網(wǎng)模式。

2.4 服務端

服務器端主要負責接受客戶端請求以及接收并存儲、更新ADDP機制客戶端發(fā)送的設備信息，其功能包括:接收并處理設備注冊請求、接受并處理設備信息請求、管理功能等，具體如下:

(1)接收并處理設備注冊請求功能

請求包含3個字段:DeviceID、AccountID和Account-Passwd，用戶身份認證通過后只需將 DeviceID、AccountID存入關(guān)系表中即可。

(2)接收并處理設備信息請求功能

AS啟動后將監(jiān)測是否接到設備上線信息，當某個設備的信息發(fā)生變化時，AS負責接收設備信息更新請求，然后更新數(shù)據(jù)庫中DL，AS更新完畢后將發(fā)送更新的DL給所有在線的其他設備，這些設備應該與發(fā)生變化的設備在同一個賬號下，并且與AS建立了WebSocket連接。

(3)管理功能

管理功能包括注冊賬號、用戶登錄認證等用戶管理功能;增刪改查設備信息表;增刪改查用戶和設備的關(guān)系表等。

2.5 ADDP機制通信協(xié)議規(guī)格

ADDP客戶端和服務端通過協(xié)議消息進行通信，協(xié)議消息用JSON格式進行描述，客戶端首先把設備信息打包成JSON各式發(fā)給AS，AS收到該數(shù)據(jù)包后更新DL并發(fā)給在線的其他設備，從而實現(xiàn)了設備之間的相互發(fā)現(xiàn)。如請求和宣告消息采用如下的格式:

{

"ADDP":{

//Auto Device Detection Protocol Meta Data

"Version":"1.0.0"

}

"ADDPMsgType" : "DeviceAdvertisement"，

/* ADDP DeviceAdvertisement Message*/

}

其中，ADDP(即Auto Device Detection Protocol)用來記錄ADDP的協(xié)議頭信息，目前定義了Version，Version格式采用 x.y.z方式表述，表示協(xié)議版本號，本例中為1.0.0。本協(xié)議規(guī)定當收到一個高于自身實現(xiàn)版本的消息時，應該拋棄該消息。

ADDPMsgType則指明了消息的類型，在本例中為設備宣告DeviceAdvertisement，從設備發(fā)向賬號服務器消息類型還有設備變更 DeviceChanged、請求查找其他設備 DeviceFindStart、停止查找其他設備DeviceFindStop;從賬號服務器發(fā)向設備的消息類型有賬號服務器返回該用戶賬號下的所有設備信息ASDeviceList、賬號服務器主動推送變更后的設備信息ASChangedDevice以及返回請求錯誤信息ASError，具體消息類型見表1。

表1 ADDP協(xié)議消息類型列表

各類型消息通過使用完整的JSON格式描述如下:

{

"addp":{

//Auto Device Detection Protocol Meta Data

"version":"1.0.0"

}，

"type" : "消息類型序列號"，

"list" : ［

{

"id" :"設備唯一的序列號"，

"name" :"設備名稱"，

"type" :"設備類型序列號"，

"desc" :"設備描述信息"，

"url" :"提供服務的設備IP和服務信息的主路徑"，

"online" :"設備是否在線"

}，

...

］}

3 測試及分析

主要測試系統(tǒng)的發(fā)現(xiàn)時間、發(fā)現(xiàn)效率、發(fā)現(xiàn)范圍以及對設備資源信息進行管理的效果。在設備發(fā)現(xiàn)測試中，用裝有Ubuntu10.04的虛擬機來模擬智能設備，虛擬機內(nèi)存為512M。設備發(fā)現(xiàn)時間的計算公式為1所示

式中:T——設備發(fā)現(xiàn)時間，T1——設備信息搜集并發(fā)送給AS上的時間，T2——服務器的處理時間 (包括寫入數(shù)據(jù)庫并進行讀取的時間)，T3——服務器處理完畢后推送給其他設備的平均時間，T3的計算公式為2所示

式中:T31——AS推送給設備D1所花費的時間，T32——AS推送給設備D2所花費的時間，T3n——AS推送給設備Dn所花費的時間，N——設備的個數(shù)。T4——設備收到并進行更新的時間。這里假設設備已注冊，不考慮設備注冊時間，不考慮設備在具體的網(wǎng)絡環(huán)境中獲得IP地址并接入互聯(lián)網(wǎng)的時間。具體設備發(fā)現(xiàn)時間測試數(shù)據(jù)見表2。

表2 設備發(fā)現(xiàn)時間測試數(shù)據(jù)

當設備為1臺時，表示服務器發(fā)現(xiàn)該臺設備上線的時間。在本測試中，只是測試10種同類型設備，在相同實驗環(huán)境下的發(fā)現(xiàn)時間，這主要是實驗平臺的限制，而實際情況設備的類型及設備所處的網(wǎng)絡環(huán)境都有可能不同。這組數(shù)據(jù)的圖表表示如圖3所示。

圖3 設備發(fā)現(xiàn)時間關(guān)系

由測試數(shù)據(jù)與其折線圖，可以看出，設備發(fā)現(xiàn)時間與網(wǎng)絡的復雜度呈現(xiàn)出一個不規(guī)則曲線關(guān)系。設備發(fā)現(xiàn)時間是處在一個一定大小的區(qū)間 (3-43毫秒)。

一般互聯(lián)互通技術(shù)標準中僅能實現(xiàn)局域網(wǎng)中的設備發(fā)現(xiàn)，并且發(fā)現(xiàn)時間數(shù)量級為秒級。從本測試結(jié)果中可知:本設備發(fā)現(xiàn)機制發(fā)現(xiàn)時間僅為數(shù)毫秒。

以上測試結(jié)果表明:ADDP機制不僅可以實現(xiàn)設備之間的相互發(fā)現(xiàn)，而且發(fā)現(xiàn)時間比同類標準少，發(fā)現(xiàn)效率比同類標準高，發(fā)現(xiàn)范圍比同類標準廣。

4 結(jié)束語

本文通過利用最新的WebSocket技術(shù)，提出了一種新的、快速而又高效的設備自發(fā)現(xiàn)機制，提出了個人域互聯(lián)網(wǎng)絡的相關(guān)概念，實現(xiàn)了基于該網(wǎng)絡的設備自發(fā)現(xiàn)模型。最后通過實驗進行測試，并對測試結(jié)果進行分析，驗證了ADDP機制的正確性和可行性。本論文只是對ADDP機制做了基礎(chǔ)分析和研究，現(xiàn)階段只是簡單實現(xiàn)了智能設備之間的無縫連接、相互發(fā)現(xiàn)、資源共享，并對設備進行統(tǒng)一管理。由于ADDP機制還不完善，尤其是上層應用框架還正在設計，處于發(fā)展的初級階段，在一些方面存在尚未精確的定義;在協(xié)議轉(zhuǎn)換方面的技術(shù)細節(jié)也需要進一步研究和確定，這些都需要我們繼續(xù)努力和改進。

［1］WANG Jing.The research of wireless digital home network［D］.Xi'an:Northwest University，2010(in Chinese).［王晶.無線數(shù)字家庭網(wǎng)絡的研究［D］.西安:西北大學，2010.］

［2］LE Xing.Digital home networking standard-the DLNA ［J］.Practical Audio-Visual Technique，2008(9)(in Chinese).［樂行.數(shù)字家庭的網(wǎng)絡標準-DLNA［J］.實用影音技術(shù)，2008(9).］

［3］LIU Yun.The research of home network standard［D］.Chengdu:University of Electronic Science and Technology of China，2006(in Chinese).［劉云.家庭網(wǎng)絡標準研究 ［D］.成都:電子科技大學，2006.］

［4］YE Mao.Research and design of IGRSprotocol and device management［D］.Chengdu:University of Electronic Science and Technology of China，2009(in Chinese).［葉茂.閃聯(lián)協(xié)議研究和設計及其設備管理機制的研究與改進［D］.成都:電子科技大學，2009.］

［5］ZHAN Hongyan.Research of IGRSand realization and perfection of its key module［D］.Xi'an:Xi'an University of Science and Technology，2006(in Chinese).［詹紅艷.閃聯(lián)協(xié)議的研究及其關(guān)鍵模塊的實現(xiàn)與改進 ［D］.西安:西安科技大學，2006.］

［6］WU Runkai.The study and application of interconnection between digital homes［D］.Guangzhou:South China University of Technology，2011(in Chinese).［吳潤凱.數(shù)字家庭間互聯(lián)互通方法的研究與應用 ［D］.廣州:華南理工大學，2011.］

［7］ZHANG Binhua.The study and application of digital home interconnection technology［D］.Guangzhou:South China University of Technology，2010(in Chinese).［張炳華.數(shù)字家庭互聯(lián)互通方法研究及其應用［D］.廣州:華南理工大學，2010.］

［8］WANG Mingjie.The study and realization of smart home gateways adaptivity［D］.Chengdu:University of Electronic Science and Technology of China，2011(in Chinese).［王明杰.家庭網(wǎng)關(guān)的自適應性的研究與實現(xiàn)［D］.成都:電子科技大學，2011.］

［9］ZHANG Yanhong.The research and implementation of the plug and control protocol stack in the digital home［D］.Nanjing:Nanjing Polytechnic University，2007(in Chinese).［張艷紅.數(shù)字家庭環(huán)境下智能設備即插即控協(xié)議棧的研究及實現(xiàn) ［D］.南京:南京理工大學，2007.］

［10］Peter Lubbers，Brian Albers，F(xiàn)rank Salim.Pro HTML5 programming:Powerful APIs for richer internet application development［M］.USA:Apress，2010:137-168.

［11］IETF HyBi Working Group.The WebSocket protocol［EB/OL］.［2011-12-30］.http://tools.ietf.org/html/draft-ietf-hybithewebsocketprotocol-17.

［12］W3C.The WebSocket API［EB/OL］.［2012-05-08］.http://dev.w3.org/html5/websockets/#websocket/.

［13］ZENG Hui.UPnP protocol research and applied techniques development［D］.Nanjing:Nanjing University of Posts and Telecommunications，2007(in Chinese).［曾輝.UPnP協(xié)議研究及應用技術(shù)開發(fā)［D］.南京:南京郵電大學，2007.］