基于個(gè)性化互動(dòng)電視系統(tǒng)框架的單元間信息交互的實(shí)現(xiàn)

夏菽蘭，王吉林

(1.鹽城工學(xué)院電氣工程學(xué)院，江蘇鹽城224051;2.鹽城工學(xué)院信息工程學(xué)院，江蘇鹽城224051)

基于個(gè)性化互動(dòng)電視系統(tǒng)框架的單元間信息交互的實(shí)現(xiàn)

夏菽蘭1*，王吉林2

(1.鹽城工學(xué)院電氣工程學(xué)院，江蘇鹽城224051;2.鹽城工學(xué)院信息工程學(xué)院，江蘇鹽城224051)

在現(xiàn)有HTML交互技術(shù)的技術(shù)上，實(shí)現(xiàn)了應(yīng)用對(duì)用戶(hù)數(shù)據(jù)的實(shí)時(shí)檢測(cè)及根據(jù)用戶(hù)數(shù)據(jù)的改變實(shí)時(shí)更新應(yīng)用內(nèi)容的功能。在UPnP AV框架基礎(chǔ)上，利用UPnP設(shè)備UDN這一參數(shù)的唯一性與不變性提出了一種多UPnP設(shè)備存在情況下，UPnP設(shè)備之間實(shí)現(xiàn)雙向數(shù)據(jù)推送的解決方案，并進(jìn)行了實(shí)際測(cè)試。

互動(dòng)電視;信息交互;實(shí)時(shí)個(gè)性化

隨著技術(shù)發(fā)展，廣播網(wǎng)絡(luò)與其他網(wǎng)絡(luò)的融合，家庭內(nèi)部設(shè)備之間的互連及各種應(yīng)用根據(jù)不同的用戶(hù)進(jìn)行個(gè)性化定制已經(jīng)成為可能。由于各種設(shè)備上硬件系統(tǒng)，支持的網(wǎng)絡(luò)協(xié)議，數(shù)據(jù)媒體格式的不同，各設(shè)備之間實(shí)現(xiàn)互聯(lián)及信息交互存在許多兼容問(wèn)題，DLNA(Digital Living Network Alliance)及UPnP(Universal Plug and Play)等概念的提出即為旨在提供一種對(duì)各種智能電器，無(wú)線設(shè)備，各種電腦普遍適用的端到端網(wǎng)絡(luò)連接，本文將在UPnP協(xié)議的基礎(chǔ)上實(shí)現(xiàn)電視與用戶(hù)設(shè)備的互聯(lián)。個(gè)性化互動(dòng)電視系統(tǒng)框架中各單元之間信息交互的實(shí)現(xiàn)過(guò)程，具體包括電視終端與服務(wù)器之間的信息交互、TV extension與服務(wù)器之間的信息交互及TV extension與用戶(hù)設(shè)備之間的信息交互，其中解決TV extension與用戶(hù)設(shè)備信息交互過(guò)程中存在的雙向數(shù)據(jù)推送問(wèn)題是本文的主要工作內(nèi)容。

1 電視終端與網(wǎng)頁(yè)服務(wù)器之間的信息交互

電視終端與應(yīng)用網(wǎng)頁(yè)服務(wù)器之間的信息交互如圖1所示。

由圖1可知電視終端與網(wǎng)頁(yè)服務(wù)器之間的信息交互主要包括3個(gè)方面，分別為初始應(yīng)用數(shù)據(jù)的傳輸，用戶(hù)偏好數(shù)據(jù)的傳輸及應(yīng)用發(fā)送給用戶(hù)的反饋信息。

1.1 初始應(yīng)用數(shù)據(jù)的傳輸

本文系統(tǒng)中的初始應(yīng)用數(shù)據(jù)的傳輸發(fā)生在電視終端解析到廣播信息中新的AIT信令信息時(shí)，該部分功能電視終端已經(jīng)完成，本文涉及的部分只包括設(shè)定AIT信令中應(yīng)用數(shù)據(jù)在網(wǎng)頁(yè)服務(wù)器上的具體位置信息。

1.2 用戶(hù)偏好數(shù)據(jù)的傳輸

此部分的用戶(hù)偏好數(shù)據(jù)傳輸是指電視終端上運(yùn)行的應(yīng)用對(duì)已經(jīng)存儲(chǔ)在服務(wù)器上的用戶(hù)數(shù)據(jù)的狀態(tài)進(jìn)行實(shí)時(shí)檢測(cè)。具體實(shí)現(xiàn)方式為通過(guò)JavaScript腳本以一定的頻率重復(fù)使用XMLHTTPRequest對(duì)象請(qǐng)求服務(wù)器上的用戶(hù)數(shù)據(jù)，并將其與前一輪獲得的數(shù)據(jù)進(jìn)行比較，如果數(shù)據(jù)發(fā)生改變，則認(rèn)為用戶(hù)狀態(tài)發(fā)生更新，這時(shí)，電視終端上運(yùn)行的應(yīng)用將通過(guò)本地JavaScript腳本結(jié)合獲得的最新用戶(hù)數(shù)據(jù)對(duì)應(yīng)用進(jìn)行動(dòng)態(tài)更新。

圖1 電視終端與網(wǎng)頁(yè)服務(wù)器之間的信息交互

在實(shí)現(xiàn)過(guò)程中，本文采用JQuery技術(shù)對(duì)XMLHTTPRequest進(jìn)行實(shí)際處理，采用JQuery的原因是JQuery較好地解決了XMLHTTPRequest在不同瀏覽器中的處理方式兼容問(wèn)題，且簡(jiǎn)化了處理過(guò)程，另外JQuery庫(kù)體積較小，不會(huì)給瀏覽器帶來(lái)過(guò)多的負(fù)擔(dān)。

1.3 應(yīng)用發(fā)送給用戶(hù)的反饋信息

由個(gè)性化互動(dòng)電視系統(tǒng)各部分之間的數(shù)據(jù)傳輸過(guò)程及所采用的通信協(xié)議及圖1，本文的設(shè)計(jì)方案中電視終端可以通過(guò)應(yīng)用服務(wù)器及TV extension向用戶(hù)發(fā)送反饋信息，此部分仍然利用XMLHTTPRequest對(duì)象實(shí)現(xiàn)。具體實(shí)現(xiàn)方式為應(yīng)用利用動(dòng)態(tài)加載JavaScript腳本的方式調(diào)用服務(wù)器端的PHP腳本，該P(yáng)HP腳本在收到與調(diào)用信息一起傳來(lái)的反饋信息時(shí)，通過(guò)TCP socket將反饋信息進(jìn)一步發(fā)送給TV extension。其中在動(dòng)態(tài)加載JavaScript請(qǐng)求PHP腳本時(shí)采用了JSONP數(shù)據(jù)傳輸方式，JSONP本來(lái)是用于實(shí)現(xiàn)跨域數(shù)據(jù)交換［1］的一種技巧，而本文的研究?jī)?nèi)容中應(yīng)用需要?jiǎng)討B(tài)請(qǐng)求的數(shù)據(jù)與原應(yīng)用數(shù)據(jù)屬于同一服務(wù)器來(lái)源，但考慮到將來(lái)可能的擴(kuò)展需求，本文直接采用JSONP方式進(jìn)行數(shù)據(jù)交換，其中服務(wù)器端腳本可以進(jìn)一步設(shè)置是否允許跨域請(qǐng)求。

本文中以動(dòng)態(tài)加載腳本的方式調(diào)用服務(wù)器端腳本時(shí)的源目的地址實(shí)例如下:

其中sendTTSCmd.php為服務(wù)器端用于向TV extension發(fā)送反饋消息的腳本，且可以向應(yīng)用返回一個(gè)簡(jiǎn)單的處理結(jié)果;speechText為應(yīng)用發(fā)送給用戶(hù)的反饋信息;handleTTSResponse為應(yīng)用端用來(lái)處理返回的JSON數(shù)據(jù)的方法。

2 TV extension與網(wǎng)頁(yè)服務(wù)器之間的信息交互

根據(jù)個(gè)性化互動(dòng)電視系統(tǒng)各部分之間的數(shù)據(jù)傳輸過(guò)程及所采用的通信協(xié)議，TV extension與網(wǎng)頁(yè)服務(wù)器之間的信息交互如圖2所示，主要包括服務(wù)器通用TV extension向用戶(hù)發(fā)送應(yīng)用的反饋信息和TV extension向服務(wù)器發(fā)送用戶(hù)數(shù)據(jù)。

圖2 TV extension與網(wǎng)頁(yè)服務(wù)器之間的信息交互

2.1 服務(wù)器向TV extension發(fā)送應(yīng)用反饋信息

對(duì)于這一部分的信息交互實(shí)現(xiàn)，本文中采用的為基本的TCP stream socket。因?yàn)門(mén)V extension無(wú)法提前獲知服務(wù)器何時(shí)會(huì)向自己發(fā)送反饋信息，而服務(wù)器只有在運(yùn)行的應(yīng)用調(diào)用其腳本時(shí)才向TV extension發(fā)送信息，因此實(shí)現(xiàn)過(guò)程中服務(wù)器端作為T(mén)CP client，TV extension作為T(mén)CP server實(shí)現(xiàn)信息的監(jiān)聽(tīng)。

2.1.1 服務(wù)器端發(fā)送數(shù)據(jù)

具體地，服務(wù)器端使用PHP腳本實(shí)現(xiàn)的簡(jiǎn)單TCP socket發(fā)送功能實(shí)例如下:

其中192.168.0.2:27016為T(mén)V extension的IP地址及接收服務(wù)器數(shù)據(jù)的端口號(hào)，此處服務(wù)器將發(fā)送給TV extension的反饋信息(speechText)封裝為JSON格式以便于TV extension端對(duì)各種收到的數(shù)據(jù)采用同一規(guī)則進(jìn)行判斷。

2.1.2 TV extension端接收數(shù)據(jù)

在Android設(shè)備上，TV extension的功能具體以Android獨(dú)立應(yīng)用(app)的形式存在，TV extension app里利用server socket對(duì)服務(wù)器(此時(shí)為T(mén)CP client)的數(shù)據(jù)進(jìn)行監(jiān)聽(tīng)。此部分的實(shí)現(xiàn)是在 UPnP TV-TTS的項(xiàng)目基礎(chǔ)上完成的，UPnP TV-TTS項(xiàng)目中已經(jīng)實(shí)現(xiàn)了中間設(shè)備(相當(dāng)于本文中的TV extension)通過(guò)server socket對(duì)電視終端發(fā)送的數(shù)據(jù)的監(jiān)聽(tīng)功能，本文主要的工作為重新定義TV extension收到服務(wù)器端數(shù)據(jù)以后的各種工作步驟，關(guān)于server socket與服務(wù)器端TCP client之間的通信連接建立過(guò)程，可以參見(jiàn)文獻(xiàn)［2］。

在本文的實(shí)現(xiàn)中，TV extension的server socket在收到數(shù)據(jù)以后，首先將數(shù)據(jù)還原為JSON對(duì)象，判斷其是否含有“ServerData”節(jié)點(diǎn)，如果有，則說(shuō)明該數(shù)據(jù)來(lái)自服務(wù)器。接著，TV extension將進(jìn)一步獲取的數(shù)據(jù)的“ServerDataType”信息，如code example 4.2中的“UseTTS”，如果此時(shí)有用戶(hù)存在，TV extension會(huì)將接收到的數(shù)據(jù)進(jìn)一步推送給用戶(hù)設(shè)備。

2.2 TV extension向服務(wù)器發(fā)送用戶(hù)數(shù)據(jù)

實(shí)現(xiàn)方案中TV extension在收到或刪除用戶(hù)數(shù)據(jù)時(shí)會(huì)將新的用戶(hù)數(shù)據(jù)或者默認(rèn)用戶(hù)設(shè)置數(shù)據(jù)發(fā)送給網(wǎng)頁(yè)服務(wù)器，網(wǎng)頁(yè)服務(wù)器收到這一請(qǐng)求后會(huì)將其中的用戶(hù)數(shù)據(jù)以TV extension的名稱(chēng)保存下來(lái)。具體地通過(guò)HTTP GET的方式將用戶(hù)數(shù)據(jù)作為請(qǐng)求的附加參數(shù)進(jìn)行傳送，實(shí)例如下:

其中，服務(wù)器端的getUserProfile.php可以獲得請(qǐng)求參數(shù)TVid與profile，并將profile的具體內(nèi)容保存為名稱(chēng)為T(mén)V1的文件。

使用HTTP［3］GET的原因?yàn)镠TTP GET是網(wǎng)頁(yè)服務(wù)器支持的基本協(xié)議類(lèi)型，其他可用的協(xié)議如HTTP PUT，HTTP POST等，可能需要對(duì)服務(wù)器作進(jìn)一步的配置，本文實(shí)際使用的HTTP協(xié)議均為HTTP GET協(xié)議。

3 TV extension與用戶(hù)設(shè)備之間的信息交互

TV extension與用戶(hù)設(shè)備之間的信息交互是本文的主要工作內(nèi)容，具體工作為在UPnP AV框架及TTS(Text To Speech)功能基礎(chǔ)［4］之上，完成用戶(hù)的實(shí)時(shí)檢測(cè)，用戶(hù)數(shù)據(jù)從用戶(hù)設(shè)備向TV extension方向的傳輸，TV extension收到用戶(hù)數(shù)據(jù)后的處理過(guò)程，及應(yīng)用反饋信息從TV extension向用戶(hù)設(shè)備方向的反向傳輸。下面將首先對(duì)UPnP基本工作過(guò)程及UPnP-TTS項(xiàng)目進(jìn)行簡(jiǎn)單介紹，并指出其用于本文工作中的不足之處。

3.1 UPnP基本工作過(guò)程

根據(jù)控制點(diǎn)與設(shè)備的連接與交互過(guò)程，UPnP網(wǎng)絡(luò)的工作過(guò)程［5］分為六步即尋址、發(fā)現(xiàn)、描述、控制、事件及展示。本文的具體工作為在此基礎(chǔ)上實(shí)現(xiàn)設(shè)備之間的雙向通信及信息交換。

在現(xiàn)有的UPnP設(shè)備框架標(biāo)準(zhǔn)及UPnP AV框架標(biāo)準(zhǔn)中，控制點(diǎn)與設(shè)備連接之后，在控制點(diǎn)發(fā)送給設(shè)備一個(gè)信息之后，設(shè)備返回的信息內(nèi)容及返回信息的時(shí)間是相對(duì)于發(fā)來(lái)的信息是固定的無(wú)法任意修改的，而本文需要實(shí)現(xiàn)在設(shè)備收到另一設(shè)備的信息之后，在一個(gè)不可預(yù)知的時(shí)間延遲之后返回一個(gè)自行設(shè)定的可變信息參數(shù)，為需要在UPnP協(xié)議的基礎(chǔ)上進(jìn)行擴(kuò)展。具體地，本文利用UDN參數(shù)的唯一性與固定性，在一個(gè)設(shè)備(此處僅指物理設(shè)備)向另一個(gè)設(shè)備發(fā)送信息時(shí)同時(shí)將自己的UDN參數(shù)發(fā)送給該設(shè)備，這樣該設(shè)備就可以判斷出在眾多的設(shè)備中信息是由哪一個(gè)設(shè)備發(fā)出的，且在需要時(shí)發(fā)送反饋信息給該特定設(shè)備。

3.2 UPnP TV-TTS項(xiàng)目基礎(chǔ)

基于TCP/IP及UPnP協(xié)議實(shí)現(xiàn)的TTS功能框架［4］如圖3所示。

圖3 基于TCP/IP及UPnP協(xié)議實(shí)現(xiàn)的TTS功能框架

圖3中的Philips電視內(nèi)嵌了為T(mén)TS特殊定制的TCP/IP通信模塊，當(dāng)遙控器選中電視屏幕上的文本信息時(shí)電視上的TTS模塊會(huì)將當(dāng)前選中的文本信息通過(guò)TCP socket發(fā)送給control point，control point在收到該信息后會(huì)將有用的文本信息通過(guò)UP-nP連接發(fā)送給用戶(hù)設(shè)備(圖中的media renderer)，用戶(hù)設(shè)備在接收到該信息后會(huì)通過(guò)內(nèi)嵌的TTS功能讀出接收到的文本信息。

3.3 基于UPnP TV-TTS項(xiàng)目實(shí)現(xiàn)的TV extension與用戶(hù)設(shè)備之間的雙向通信

3.3.1 TV extension與用戶(hù)設(shè)備之間的基本通信過(guò)程

圖4 基于本文的個(gè)性化互動(dòng)電視系統(tǒng)實(shí)現(xiàn)的TTS功能框架

在本文的工作過(guò)程中，TV extension相當(dāng)于圖3中的control point，用戶(hù)設(shè)備相當(dāng)于圖3中的media renderer。與圖3不同的是，本文使用的Philips TV沒(méi)有內(nèi)嵌TCP/IP TTS通信模塊，且本文中設(shè)定的電視發(fā)送給用戶(hù)的反饋信息來(lái)自運(yùn)行在電視終端上的應(yīng)用，因此實(shí)際上與TV extension進(jìn)行通信的為網(wǎng)頁(yè)服務(wù)器。另外圖3中的用戶(hù)設(shè)備(media renderer)與中間設(shè)備(control point)之間的通信是單向進(jìn)行的，即用戶(hù)設(shè)備只需要接收中間設(shè)備發(fā)送來(lái)的文本信息并讀出。而本文中需要用戶(hù)設(shè)備首先將自己的偏好設(shè)置數(shù)據(jù)通過(guò)中間設(shè)備(TV extension)傳送給應(yīng)用，為此需要實(shí)現(xiàn)中間設(shè)備與用戶(hù)設(shè)備的雙向數(shù)據(jù)推送。

相對(duì)于圖3，以TTS功能為個(gè)性化案例，本文基于個(gè)性化互動(dòng)電視系統(tǒng)實(shí)現(xiàn)的TTS功能框架如圖4所示。

圖5 TV extension與用戶(hù)設(shè)備之間的基本通信過(guò)程

前述已經(jīng)闡明了圖4中電視終端、網(wǎng)頁(yè)服務(wù)器及TV extension之間的信息交互，TV extension與用戶(hù)設(shè)備之間的信息交互過(guò)程如圖5所示，其中為方便描述，仍然保留TV extension與服務(wù)器之間的信息交互部分，其中假設(shè)UPnP設(shè)備搜索與描述部分的功能已經(jīng)完成。用戶(hù)設(shè)備需要向TV extension推送偏好設(shè)置數(shù)據(jù)，同時(shí)TV extension需要向用戶(hù)推送TTS文本信息。由于 media renderer不具備向control point主動(dòng)推送數(shù)據(jù)的功能，因此圖3中中間設(shè)備僅具有 control point功能，用戶(hù)設(shè)備僅具有media renderer功能的實(shí)現(xiàn)機(jī)制不能滿(mǎn)足本文的工作需求。同時(shí)由于物理設(shè)備在具體實(shí)現(xiàn)UPnP功能時(shí)可以同時(shí)具有多種邏輯功能，因此本文的初步設(shè)想是使得TV extension與用戶(hù)設(shè)備均具有control point與media renderer的功能，從而完成雙向的數(shù)據(jù)推送。二者在作為media renderer時(shí)都通過(guò)Play-Text接口接收傳送給自己的數(shù)據(jù)。

3.3.2 用戶(hù)向TV extension發(fā)送數(shù)據(jù)的流程

用戶(hù)設(shè)備作為control point向TV extension推送自己的偏好設(shè)置信息時(shí)的信息交互是TV extension作為media renderer在收到PlayText發(fā)來(lái)的用戶(hù)數(shù)據(jù)信息之后觸發(fā)PlayTextCB回調(diào)函數(shù)，PlayTextCB將進(jìn)一步完成用戶(hù)數(shù)據(jù)向應(yīng)用服務(wù)器的推送。

3.3.3 TV extension向用戶(hù)設(shè)備發(fā)送數(shù)據(jù)的流程及用戶(hù)離開(kāi)時(shí)的數(shù)據(jù)處理

用戶(hù)設(shè)備作為 media renderer在收到 PlayText發(fā)來(lái)的TTS文本信息之后觸發(fā)PlayTextCB回調(diào)函數(shù)，PlayTextCB將會(huì)調(diào)用Android設(shè)備內(nèi)嵌的TTS功能讀出收到的TTS文本信息。另外本文的TV extension端control point監(jiān)聽(tīng)了設(shè)備離去事件，用戶(hù)離開(kāi)時(shí)會(huì)發(fā)送離開(kāi)消息給TV extension，觸發(fā)設(shè)備離開(kāi)事件，此時(shí)TV extension會(huì)將一套應(yīng)用默認(rèn)設(shè)置數(shù)據(jù)發(fā)送給服務(wù)器并覆蓋原來(lái)的用戶(hù)數(shù)據(jù)。

3.3.4 TV extension與用戶(hù)設(shè)備之間實(shí)現(xiàn)雙向數(shù)據(jù)推送時(shí)存在的問(wèn)題及本文提出的解決方案

在本文的個(gè)性化系統(tǒng)設(shè)計(jì)中，TV extension向用戶(hù)設(shè)備發(fā)送數(shù)據(jù)的流程及用戶(hù)離開(kāi)時(shí)的數(shù)據(jù)傳輸過(guò)程總是在用戶(hù)向TV extension發(fā)送數(shù)據(jù)之后，因?yàn)門(mén)V extension只有在已經(jīng)有用戶(hù)連接到網(wǎng)絡(luò)并獲得該用戶(hù)的個(gè)人偏好設(shè)置數(shù)據(jù)之后，才有可能發(fā)送反饋信息給該設(shè)備。這里存在的一個(gè)問(wèn)題是，當(dāng)系統(tǒng)中有多個(gè)相同類(lèi)型的設(shè)備存在時(shí)(本文僅考慮media renderer設(shè)備類(lèi)型)，TV extension將獲得多個(gè)設(shè)備描述信息，而之前用戶(hù)設(shè)備在使用Play Text發(fā)送信息時(shí)不會(huì)自動(dòng)將自己的設(shè)備位置信息同時(shí)發(fā)送給TV extension，因此TV extension無(wú)從獲知之前發(fā)送信息的是哪一個(gè)用戶(hù)設(shè)備，同時(shí)由于TV extension沒(méi)有獲知發(fā)來(lái)信息的設(shè)備是哪一個(gè)，因此當(dāng)檢測(cè)到設(shè)備離開(kāi)事件時(shí)，TV extension也無(wú)法確認(rèn)當(dāng)前離開(kāi)的設(shè)備是之前發(fā)送信息的設(shè)備還是無(wú)關(guān)設(shè)備。

基于上述問(wèn)題描述，本文基于設(shè)備device UDN (Unique Device Name)這一參數(shù)的唯一性與不變性提出了一種解決方案，具體方式為將用戶(hù)的device UDN參數(shù)也包含在用戶(hù)向TV extension發(fā)送的數(shù)據(jù)之中，詳細(xì)描述如圖6所示。

如圖6用戶(hù)設(shè)備在發(fā)送自己的偏好設(shè)置數(shù)據(jù)之前，將自己的device UDN參數(shù)也加入到該數(shù)據(jù)之中，這樣TV extension在收到用戶(hù)數(shù)據(jù)之后就可以從中獲得用戶(hù)的device UDN參數(shù)，并在之后發(fā)送反饋信息給用戶(hù)時(shí)利用該device UDN作為PlayText的參數(shù)定位到用戶(hù)設(shè)備。另外，當(dāng)TV extension檢測(cè)到設(shè)備離開(kāi)事件時(shí)，也可以將離開(kāi)設(shè)備的UDN與該當(dāng)前用戶(hù)的device UDN參數(shù)進(jìn)行比較，從而判斷出離開(kāi)的設(shè)備是否為正在使用的用戶(hù)設(shè)備，如果離開(kāi)的設(shè)備是正在使用的用戶(hù)設(shè)備，TV extension將會(huì)發(fā)送默認(rèn)的應(yīng)用設(shè)置參數(shù)給應(yīng)用服務(wù)器覆蓋之間的用戶(hù)數(shù)據(jù)，并將之前存儲(chǔ)的用戶(hù)device UDN參數(shù)及用戶(hù)數(shù)據(jù)刪除。

圖6 TV extension與用戶(hù)設(shè)備之間進(jìn)行雙向數(shù)據(jù)推送的解決方案

4 結(jié)語(yǔ)

闡述了個(gè)性化互動(dòng)電視系統(tǒng)框架中各單元即電視終端與服務(wù)器之間、TV extension與服務(wù)器之間及TV extension與用戶(hù)設(shè)備之間信息交互的實(shí)際實(shí)現(xiàn)過(guò)程，在UPnP AV基礎(chǔ)之上提出了一種多UPnP設(shè)備存在情況下在UPnP設(shè)備之間實(shí)現(xiàn)雙向數(shù)據(jù)推送的解決方案，并描述了其實(shí)現(xiàn)方式。

［1］ http://developer.yahoo.com/javascript/howto-proxy.html［EB/ OL］.2010.

［2］ 小胖’s Blog.簡(jiǎn)單的tcp socket編程及分析［EB/OL］.http:// eshock.blogbus.com/logs/43398355.html，2009.

［3］ Hypertext Transfer Protocol—HTTP/1.1，Internet RFC 2616［S］. http://www.w3.org/Protocols/rfc2616/rfc2616.html，2004.

［4］ Yu Weiwei.Text-To-Speech Interface for TV［Z］.Internship Report for Fontys University of Applied Sciences，2012.

［5］ UPnPTMDevice Architecture v1.1［S］.2008.

夏菽蘭(1969- )，女，副教授，研究方向?yàn)殡娮蛹夹g(shù)與信息處理;

王吉林(1966- )，男，江蘇鹽城人，鹽城工學(xué)院信息學(xué)院教師，副教授，主要研究方向?yàn)殡娮蛹夹g(shù)與信息處理。

Implementation of Information Interaction among the Units Based on Personalized Interactive Television System

XIA Shulan1*，WANG Jilin2
(1.School of Electrical Engineering，Yancheng Institute of Technology，Yancheng Jiangsu 224051，China; 2.School of Information Engineering，Yancheng Institute of Technology，Yancheng Jiangsu 224051，China)

The communication between assistance device and user device is based on UPnP AV architecture.The paper proposes a solution to realize the two-way data push between two UPnP devices when there are multiple devices existing via taking use of the uniqueness and stability of the deivce parameter UDN.

interactive television;information interaction;real-time personalization

10.3969/j.issn.1005－9490.2014.02.010

TN919.8;TN943

A

1005－9490(2014)02－0215－06

2013-06-07修改日期:2013-07-05

EEACC:6430J