DLNA介紹(包含UPnP,2011/6/20 更新)

這部分的內容大多來源於網絡及官方文檔,依照本身的翻譯理解整理所成。東西比較多,從頭慢慢看仍是可以懂個大概的。git

 

文件夾:web

1、DNLA的創建瀏覽器

2、DLNA的成員網絡

3、DLNA標準的制定架構

4、DLNA的設備app

5、DLNA的架構框架

6、雲時代的數字家庭(待填坑)ide

 

擴展閱讀I: UPnP的工做過程------------DLNA基礎協議框架佈局

擴展閱讀II UPnP AV(Audio/Video) Architecture---------------DLNA媒體應用框架)ui

 

1、DNLA的創建

 

DLNA 成立於2003624其前身是DHWGDigital Home Working Group 數字家庭工做組),由Sony、Intel、Microsoft等發起成立、旨在解決我的PC ,消費電器,移動設備在內的無線網絡和有線網絡的互聯互通,使得數字媒體和內容服務的無限制的共享和增加成爲可能。DLNA的口號是Enjoy your music, photos and videos, anywhere anytime。該組織的官方站點是http://www.dlna.org . 頁面主色調green,black,white,silver和gray,後面要講到的UPnP的主業也是相同的調調,這兩個關係挺大的,後面講。

 

2、DLNA的成員

 

這個組織將增長者分爲兩個層次,最高層次爲promoter,  其次爲contributor。promoter制定標準和協議,contributor可以分享這個組織的資源,也可以提交標準,參與討論。現在絕大多數的電子製造商都增長了該組織,至少是contributor,而且年費還很是貴。成員名單可以從http://www.dlna.org/about_us/roster/中可以找到。

 

        下圖是2008年DLNA的promoter:

 

下圖是2011年的promoter:

 

 

         從上面兩個圖咱們可以看見,DLNA的骨幹成員包含以Intel爲首的芯片製造商;以HP爲首的PC製造商,以Sony,Panasonic,Sharp,Samsung,LG 爲首的家電、消費電子製造商;以CISCO,HUWEI,MOTOROLA,ERICSSON爲首的電信設備/移動終端/標準商;一家獨大的Microsoft軟件/操做系統商等等。

 

        值得注意的有幾點:

        1.DLNA這個東西基本Intel,Microsoft兩個領域巨頭在推,一個搞芯片,一個搞系統。AMD沒出現在2011的promoter名單中;Google來年會不會摻一腳很差說。還有QUALCOMM也參加進來了,這幾年的智能手機芯片處理器他家的也比較多,而且他家還有很是多專利可以吃。

        2.2011就剩HP一個大PC商了,其它大PC商如Acer,Asus都還不是promoter,他們確定要搶着增長的。lenovo不只從promotor名單中消失了,天然也不會是contributor了,和AMD同樣。最開始時lenovo是很是積極的,在DHWG的時候也是骨幹成員,回來中國搞了一個「IGRS閃聯」,退出的緣由不知道和這個有沒有關係。IGRS在很是大程度上和DLNA是比較相似的,框架協議和UPnP也是比較像的。

        3.Awox和Cablelabs都是作互聯多媒體設備的。Broadcom主要是作移動消費電子,有硬件solution,也有產芯片。

4.ACCESS(愛可視)是作軟件的。現在軟件的需求很是大,給第三方提供軟件solution是一塊很是大的蛋糕。cyberlink和arcsoft也在作這方面,已經有些成熟的軟件solution了,像EMC,NeuSoft也有在作。

5.運營商開始增長了,像at&t美國電報電話公司,at&t也挺厲害的,處處搞簽約機,像是跟PSP VITA也簽了。之後中國移動聯通不知道會不會也跑來參加(有點難...)。

        6.dts和dolby都是作音視頻標準的,他們基本是跑來收錢的,你機器上到他們的專利你就得付錢,跟之後確定其它人也會跑來收錢。

 

3、DLNA標準的制定

 

該組織旨在創建一個基於開放的工業標準的互操做平臺,並將確立技術設計規則,供企業開發數字家庭有關的產品。其工做目標是依據開放工業標準制定媒體格式,傳輸和協議互操做性的指南和規範,和其它工業標準化組織進行聯絡,提供互操做性測試,並進行數字家庭市場計劃的制定和實施。

        DLNA並不是創造技術,而是造成一種解決的方案,一種你們可以遵照的規範。因此DLNA選擇的各類技術和協議都是眼下所應用很是普遍的技術和協議。因此很是多家都要參加,但願DLNA採納本身的協議和標準,之後本身好辦事,可以的話順便吃點專利費。慷慨向上確定打只是Intel和Microsoft的,僅僅能跟着他們走,可以提起其它方面的協議和標準。DLNA的標準寫在DLNA GUIDELINES裏面,就是你們開會一塊兒寫出來的,再開會不停改動的一個standard,一個specification。參加DLNA的商家必須按這個標準走,這樣你們的設備才幹相互通訊。

 

4、DLNA的設備


在講DLNA的架構以前先講一下DLNA規定的設備分類,這些設備就是DLNA標準運行的物理和邏輯對象。

 


這是一個DLNA 設備的類圖。


1.Home NetWork Device(HND)。這類設備指家庭設備,具備比較大的尺寸及較全面的功能,主要與移動設備差異開來,下屬5類設備:

(1)Digital Media Server(DMS)。數字媒體server,提供媒體獲取、記錄、存儲和輸出功能。同一時候,內容保護功能是對DMS的強制要求。DMS老是包括DMP的功能,並且肯能包括其它智能功能,包括設備/用戶服務的管理;豐富的用戶界面;媒體管理/收集和分發功能。DMS的樣例有PC、數字機頂盒(附帶聯網,存儲功能)和攝像機等等。

(2)DMP。數字媒體播放器。能從DMS/M-DMS上查找並獲取媒體內容並播放和渲染顯示。比方智能電視、家庭影院等。

(3)DMC。數字媒體控制器,查找DMS的內容並創建DMS與DMR之間的鏈接並控制媒體的播放。如遙控器。

(4)DMR。數字媒體渲染設備。經過其它設備配置後,可以播放從DMS上的內容。與DMP的差異在於DMR僅僅有接受媒體和播放功能,而沒查找有瀏覽媒體的功能。比方顯示器、音箱等。

(5)DMPr。數字媒體打印機,提供打印服務。網絡打印機,一體化打印機就屬於DMPr。

2.Mobile Handheld Devices(MHD)手持設備。相比家庭設備,手持設備的功能相對簡化一些,支持的媒體格式也會不一樣。

(1)M-DMS。與DMS相似,如移動電話,隨身音樂播放器等。

(2)M-DMP。與DMP相似。比方智能移動電視。

(3)M-DMD。移動多媒體下載設備。如隨身音樂播放器,車載音樂播放器和智能電子相框等

(4)M-DMU。移動多媒體下載設備。如攝像設備和手機等。

(5)M-DMC。與DMC相似。P如DA,智能遙控器。 手持設備未定義M-DMR,因爲手持設備會講究便利性,會附加查找控制功能,

要否則就僅僅是普通的移動電視或收音機了。

3.Networked Infrastructure Devices (NID) 聯網支持設備。

(1)Mobile Network Connectivity Function (M-NCF)。移動網絡鏈接功能設備。提供各類設備接入移動網絡的物理介質。 DLNA的但願是全部實現無線化。

(2)Interoperability Unit (MIU)媒體交互設備。提供媒體格式的轉換以支持各類設備需要。

 

        設想一下這樣一個scenario:你下了班回到家,掏出手機撥到家庭模式,而後就在手機上遙控打開了等離子電視和PC,而後把訂閱的新聞經過PC下載完畢後打到等離子電視上播放。這時手機就是一個DMC/M-DMC,等離子電視是一個DMR,PC就是DMS。而後你手機上收到一張朋友從巴西傳來的照片,你看完以後把它同步到PC上存儲起來,這樣手機現在的身份是M-DMU,而後你把這張圖片放到電子相框裏面。這個電子相框就是一個M-DMD,相框也有play的能力,因此他又是一個M-DMP。因此說這些設備的功能角色都是不定的,界限也不是那麼嚴格。在DLNA Guidelines v1.0的時候尚未智能手機,後來在v1.5增長了。這個設備分類僅僅是定義了功能,而且功能也會變的。之後還會出其餘新設備,像pad,tab,touch各類各樣,到時候標準也會變的。

 

 

5、DLNA的架構

 

DLNA架構是個互聯繫統,所以在邏輯上它也相似OSI(Open System Interconnection,開放系統互連)七層網絡模型。

DLNA架構分爲例如如下圖7個層次:

                                                   DLNA ARCHITECTURE

 

(1) NetWorking Connectivity 網絡互聯方式:包含物理鏈接的標準,有有線的,比方符合IEEE802.3標準的Ethernet,;有無線

,比方符合IEEE802.11a/g標準的WiFi,能作到54Mbps,藍牙(802.15)等,技術都很是成熟。現在OFDM和MIMO(802.11n)已經能作到300Mbps了,早就超過比較普及的100Mbps的Ethernet了,僅僅只是產品尚未普及,之後確定會用到。

 

(2) NetWorking Stack 網絡協議棧:DLNA的互聯傳輸基本上是在IPV4協議簇的基礎上的。用TCP或者UDP來傳都可以。這一層至關於OSI網絡層。

 

(3)Device Discovery&Control 設備發現和控制。

         這個層次是比較essential的,是DLNA的基礎協議框架。DLNA用UPnP協議來實現設備的發現和控制。如下重點看一下UPnP。

         這一部分可以看一下http://upnp.org/sdcps-and-certification/standards/device-architecture-documents/裏的文檔。UPnP的工做過程 一文也作了具體說明。如下歸納總結性地說一說。

         UPnP,英文是Universal Plug and play,翻譯過來就是通用即插即用。UPnP最開始Apple和Microsoft在搞,後來Apple不作了,Microsoft還在繼續作,Intel也加進來作,Sony,Moto等等也有增長。UPnP有個站點http://www.upnp.org/,咱們發現DLNA的網頁和UPnP的網頁很是像,顏色也差點兒相同,就可以知道他們關係很是好了。DNLA主要是在推UPnP。

 微軟官方站點對UPnP的解釋:通用即插即用 (UPnP) 是一種用於 PC 機和智能設備(或儀器)的常見對等網絡鏈接的體系結構,尤爲是在家庭中。UPnP 以 Internet 標準和技術(好比 TCP/IP、HTTP 和 XML)爲基礎,使這種設備彼此可本身主動鏈接和協同工做,從而使網絡(尤爲是家庭網絡)對不少其它的人成爲可能。

        舉個樣例。咱們在本身的PC(win7)裏面打開網絡服務的UPnP選項,而後再家庭網絡中共享一個裝着視頻的目錄,而後買一臺SmartTV回來打開就可以找到這臺PC的共享目錄,而後就直接在電視上選文件播放了。

        UPnP的另一個做用是給家庭網內的devices作本身主動的網絡地址轉換NAT(NAT,Network Address Translation)和port映射(Port Mapping),因爲家庭網絡裏面沒有那麼多IP,所有的devices可能都要經過同一個ip出去。轉換映射以後,家庭網絡內外的devices就可以經過internet自由地相互鏈接,而不受內網地址不可訪問的阻礙。

UPnP Device Architecture 1.0中會說明設備是如何經過UPnP來相互發現和控制,以及傳遞消息的。咱們會專門用一章的篇幅來說一下UPnP Device Architecture,可見下文中的擴展閱讀I: UPnP的工做過程

 

(4)Media Management媒體管理。媒體管理包含媒體的識別、管理、分發和記錄(保存),UPnP AV Architecture:1 and UPnP Printer Architecture:1這兩個屬於UPnP的文檔會說明怎樣進行媒體管理。我將在 擴展閱讀II:UPnP AV Architecture 一文中略微具體介紹UPnP AV設備和CP之間的交互模型及媒體的控制。

 

        UPnP AV Architecture 定義了UPnP AV設備間媒體傳送以及和CP間的交互。UPnP AV也定義了兩種UPnP AV設備:UPnP AV MediaServer(MS)和UPnP AV MediaRender(MR),以及他們具備的4種服務:

1)Content Directory Service(CDS):能將可訪問的媒體內容列出。

2)Connection Manager Service(CMS):決定媒體內容可以經過何種方式由UPnP AV Media Server傳送至UPnP AV MediaRender。

3)AVTransport Service:控制媒體內容,比方播放、中止、暫停、查找等。

4)Rendering Control Service:控制以何種方式播放內容,比方音量、靜音、亮度等。

         UPnP Printer Architecture:1 定義了打印設備和CP的交互模型,這將再也不細說。

 

(5) Media Transport 媒體傳輸:這一層用HTTP(HyperText Transfer Protocol)超文本傳輸協議。就是平時咱們上網用的媒體傳輸協議。HTTP用TCP可靠傳輸,也有混合UDP方式的HTTP。現在HTTP的最新版本號是HTTP1.1。可選協議是RTP。

      exsample:咱們輸入一個網址,回車,給server發一個request,用TCP咱們就可以等server給咱們消息,說明server收到咱們的消息了,不然咱們就重發;接着server給咱們TCP包,咱們收一個就給server回信說咱們收到了,要是server收不到回信,他就以爲包丟掉了,會再傳一個相同的包過來。不停地回信就是會比較慢。

       那假設咱們用UDP會如何?就是說咱們不給server回信說咱們收到編號是x的包了,server也就不給咱們重發丟掉的包了,這樣咱們就丟包了。

       但是咱們傳stream的時候,比方視頻流,不用存,看完就完了,這樣的時候就可以用UDP來傳。加上局域網裏面QoS原本就很是高,丟包都是不太可能的。因此UDP確定會用。局域網多播的時候也用UDP,這個在後面講。

      媒體的傳輸方案例如如下:

1)從DMS/M-DMS至DMP/M-DMP,即便不立刻播放。

2)從一個DMS到還有一個DMS,這時接收方DMS播放接收媒體內容,表現爲一個DMP;也可以不立刻播放,可能僅僅是存儲或者處理。

 

     媒體傳輸 模式有三種:

1)流傳輸。當DMR/DMP需要實時渲染接收媒體,媒體具時序性。

2)交互傳輸。不包括時序的媒體,如圖片傳輸。

3)後臺傳輸。非實時的媒體傳輸,比方上傳下載等。

 

(6)Media Formats媒體格式。格式Formats在這裏等同於編碼格式Codec,平時咱們說的編碼格式比方Mpeg-2,AVC,x264就是視頻編碼格式;PCM,mp3(MPEG-2 Layer 3),aac,flac就是音頻編碼格式。而avi,rmvb,mkv這些是媒體封裝格式,包括視頻音頻可能還有字幕流。比方一個常見的後綴爲mkv的文件,它的視頻Codec是x264,音頻是aac,它的視音頻編碼屬於Mpeg-4 Codec Family。

 

         咱們知道不一樣設備對編碼格式的支持能力不一樣,Media Formats這一部分規定了設備應該具備的格式支持能力。如下的表是DLNA支持的所有編碼格式:

                                                   DLNA-proved format

Video

Audio

Images

MPEG-1

MPEG-2

H.263

MPEG-4 Part 2

MPEG-4 Part 10

WMV9

VC-1

 

LPCM

MPEG-1/2 L2

MPEG-1/2 L3

MPEG-4 AAC LC

MPEG-4 AAC LTP

MPEG-4 HE AAC

MPEH-4 BSAC

AC-3

ATRAC3plus

WMA

WMA Professional

AMR

AMR-WB+

G.726

JPEG

PNG

GIF

TIFF

 

 

針對家庭設備和手持設備,DLNA有不一樣的格式規定:

 

 

(7)Remote UI 遠程用戶接口。說白了就是遙控器。比方說有個TV,咱們說不管是用遙控器仍是直接在TV上按button,效果是同樣的。只是二者button的排列布局是不同的。好了,現在到DLNA了,我想用手機當遙控器可不可以?固然可以,僅僅要得到TV上button的功能,傳到手機上來,模擬一個遙控器就行了。DLNA現在想用瀏覽器的方式,TV給你一個XML,手機上就出現遙控器界面了,有點像webQQ,webOS那種,這樣在手機上就不需要client了,TV功能更新了,手機直接跟TV要新的XML,很是方便。

-------------------------------------------------------------------------------------------------------------------------------

 

擴展閱讀I: UPnP的工做過程

 

UPnP的工做過程分爲6步:

(1)尋址(Addressing)。

  地址是整個UPnP系統工做的基礎條件,每個設備都應當是DHCP(Dynamic Host Configuration Protocol 動態主機配置協議)的客戶。當設備首次與網絡創建鏈接後,利用DHCP服務,使設備獲得一個IP地址。這個IP地址可以是DHCP系統指定的,也可以是由設備選擇的。當局域網內沒有提供DHCP服務時,UPnP設備將依照Auto-IP的協議,從169.254/169.16地址範圍獲取一個局域網內惟一的IP地址。設備還可以使用friendly name,這就需要域名解析服務(DNS)來轉換name和IP。這個過程用到的東西都是現存的,而且是很是普及的,市面上買的路由器都會有。

(2)發現(Discovery)。

       發現是 UPnP工做第一步。 當一個設備被加入到網絡後,UPnP的發現協議贊成該設備向網絡上的Control Points(CPs)通知(advise)本身擁有的服務相同,當一個CP被加入到網絡後,UPnP發現協議贊成該CP搜索網絡上可用的設備這兩種狀況下的組播消息一般是設備和服務的基本信息,如它的類型惟一標識符,當前狀態參數等等。要注意設備信息和服務信息都是要組播出去的。發現的過程可以用如下Figure 1-1來描寫敘述。

 

 

         如下具體敘述UPnP發現設備用到的協議:SSDP(Simple Service Discovery Protocol,簡單服務發現協議),說明設備是怎樣向網絡通知或者撤銷本身可以提供的服務;CP是怎樣搜索設備以及設備是怎樣迴應搜索的。

        SSDP格式套用HTTP1.1的部分消息頭字段,但是和HTTP不一樣,SSDP是採用UDP傳輸的,而且SSDP沒有Message Body,就是說SSDP僅僅有信頭而沒有信件內容的。

SSDP第一個要填充的字段是star - line,說明這是個什麼類型的消息。

比方填"NOTIFY * HTTP/1.1/r/n",就說明這個SSDP消息是個通知消息,通常設備增長網絡或者離開網絡都要NOTIFY,更新本身的服務後也要NOTIFY一下。別的設備看見這個消息的star - line就知道有設備狀態變了,本身就打開這個消息看一下有沒有需要更新的。假設填"NOTIFY * HTTP/1.1/r/n",就要填LOCATION字段,填一個description URL,CP可以經過這個地址來取得設備的具體信息。

填"M-SEARCH * HTTP/1.1/r/n"就是要搜索了;respone別人的搜索就填"HTTP/1.1 200 OK/r/n"。

        SSDP第二個要填充的字段是目的地址HOST。比方填上"HOST: 239.255.255.250:1900",就是組播(multicast)搜索,這裏239.255.255.250是組播地址,就是說這條消息會給網絡裏面該組地址的設備發,1900是SSDP協議的port號。假設HOST地址是特定地址,那這就是單播(unicast)。Respone不填這個字段,他會在ST字段裏面填respone address,就是發來搜索信息的設備的地址,Respone消息的話還會發送一個包括本身地址URL的字段,Respone的意思就是跟Searcher說:我好像是你要找的人,個人電話是XXX,具體狀況請CALL我。Respone也是UDP單播。

日後的字段就不細說了。經過字段的組合可以發送很是多不一樣的信息。

 

(3)描寫敘述(Description)

       前面咱們說了CP想要一個device更具體的信息,就打給它的URL跟它要。返回來的東西一般是個XML(Extensible Markup Language,是種結構化的數據。和HTML比較像,有tag和data,具體不說了本身去查),描寫敘述分爲兩部分:一個是device description,是device的物理描寫敘述,就是說這個device是什麼;另外一個是service descriptions,就是device的服務描寫敘述了,就是device能幹些什麼。這些device和device service的描寫敘述的格式也是有要求的,開發商也可以本身定義,僅僅要符合UPnP Forum的規範。

        這裏略微解釋一下設備描寫敘述和服務描寫敘述。

        首先說設備,比方一個家庭影院,有顯示屏,有功放音響,還有藍光機。那麼這個家庭影院home threatre,就是一個根設備(root device),它下屬有Screen,Amplifier,BDplayer這些從設備。home threatre的描寫敘述XML中會有一個device list,列出Screen,Amplifier,BDplayer這些設備的基本信息及這些設備描寫敘述的URL,以及設備的presentationURL(這相似於webserver,經過訪問presentationURL,本地會載入一個網頁,在這個網頁上可以操做設備及其餘擁有的服務);還會有一個sevice list,裏面列出home threatre可調用的服務基本信息及服務描寫敘述URL。

       再來是服務,經過訪問服務描寫敘述URL,可以取得服務描寫敘述XML,裏面會具體介紹服務的信息,包含幹什麼用的,屬於哪一個設備,有哪些action,需要哪些參數,怎麼調用等等。

 

(4)控制(Control)

       拿到device description和service descriptions之後,那咱們怎麼去遙控這些設備呢?

       在設備描寫敘述部分,device description還有關於怎樣控制device的描寫敘述,會給出一個Control URL,CP可以向這個URL發送不一樣的控制信息就可以控制device了,而後device也可以返回一個信息反饋。

這樣的CP和device之間溝通訊息依照Simple Object Access Protocol (SOAP)的格式來寫。SOAP經過HTTP來傳,現在的版本號是1.1,叫作SOAP 1.1 UPnP Profile。這個Profile把控制/反饋信息分紅三種:UPnP Control Request,UPnP Control Response和UPnP Control Error Response,都比較好理解。SOAP協議是有信內容Body的,和SSDP不同。消息Body裏面就可以寫想調用的動做了,叫作Action invocation,可能還要傳參數,比方想播放一個視頻,要把視頻的URL傳過去;device收到後要respone,表示能不能運行調用,出錯的話會返回一個錯誤代碼。

 

(5)事件(Eventing)

         在服務進行的整個時間內,僅僅要變量值發生了變化或者模式的狀態發生了改變,就產生了一個事件,該事件服務提供者(某設備的某個服務)會把該事件向整個網絡進行多播(multicast)。而且,CP也可以事先向事件server訂閱事件信息,就像RSS訂閱同樣,保證將該CP感興趣的事件及時準確地單播傳送過來(unicast)。

 

如下是一個Unicast eventing 的architecture圖,CP是subscriber,server是publisher。

 

Unicast eventing architecture

      subscriber(通常是個CP)向publisher(通常是個service)發送訂閱消息(subscribe),更新訂閱消息(renewal),退訂消息(cancel)。publisher向subscriber推送訂閱(event:SIDX)。

 

      事件的訂閱和推送這塊用的通訊協議是GENA(General Event Notification Architecture) ,經過HTTP/TCP/IP傳送。GENA的格式就不細說了,具體請參閱UPnP-arch-DeviceArchitecture-v1.1。如下列出訂閱過程供參考:

1.訂閱。subscriber發送訂閱消息主要包括事件URL(evenURL),服務ID號(service identifier),這兩個可以在設備服務描寫敘述信息中找到,以及寄送地址(delivery URL)。還會包括一個訂閱期限(duration)。

2.成功訂閱。publisher收到訂閱信息,假設容許訂閱的話就會爲每個新subscriber 生成一個惟一的subscriber identifier並記錄subscriber 的duration和delivery URL。還會記錄一個順序增加event key用來保證事件確實推送到subscriber那裏。比方說有個新事件,key是6,而後把這個事件推送給某個subscriber那裏,subscriber那裏記錄的event key是4,現在收到的事件key是6,他就知道他沒收到key爲5的事件,這樣他就向publisher索要漏收的事件,從而保證兩方變量值或狀態的一致。

3.首次推送。訂閱容許訂閱以後還會向subscriber發送一組初始變量或狀態值,進行首次同步。

4.續訂。subscriber必須在訂閱到期前發送renewal續訂。

5.訂閱到期。訂閱到期後publisher會把subscriber的信息刪除,subscriber又回到訂閱前的狀態。

6.退訂。subscriber發送cancel信息將會取消訂閱。subscriber因非正常退出網絡的話,則不會退訂直到訂閱到期。

7.訂閱操做失敗信息。當訂閱、續訂和退訂不能被publisher接收或者出現錯誤時,publisher會發送一個錯誤代碼。

 

        再簡單說下多播(multicast,或者叫組播,本文中二者等同)和單播。even的組播採用UDP/IP,和SSDP同樣,就是port號變成了7900。下圖是幾個協議的所處層的位置,可以清楚地看到它們之間的區別。首先關於IP多播,要知道僅僅存在UDP多播,沒有TCP多播這回事。爲何呢?多播的重點是提升網絡效率,將同一數據包發送給儘量多的可能未知的計算機。像這樣的對網內所有設備的頻繁消息通知採用多播是爲了減少網絡負擔,SSDP也是同樣。

       但是SSDP和multicast這樣的採用UDP方式的協議存在一個問題,就是可靠性不夠。解決的辦法就是屢次通知,但是通常不會超過三次以避免添加網絡負擔,這樣就得不償失了。像SSDP的話會採用按期廣播advertice的方式,使各類各樣緣由而沒收到advertice的CP又一次得到advertice,又攻克了UDP丟包的問題。

       前面在尋址的時候用到的DHCP用的是UDP廣播(broadcast)。當一個新的設備增長網絡時,他想要分個IP,但又不知道DHCPserver的IP地址,因此他就在網內廣播,用255.255.255.255地址來通知所有計算機。DHCPserver收到請求後會爲他申請並返回一個IP地址。

 

 

(6)表達(Presentation)

 僅僅要獲得了設備的URL,就可以取得該設備表達的URL,取得該設備表達的HTML,而後可以將此HTML歸入CP的本地瀏覽器上。這部分還包含與用戶對話的界面,以及與用戶進行會話的處理。所以設備表達可以理解成「遙控器」。這部分定義描寫敘述界面,規範界面以及傳輸界面內容。遠程界面是供CP用戶使用的,CP用戶經過遠程界面完畢設備描寫敘述的獲取,控制設備,訂閱收取設備事件等等。

 

好了, 到此,UPnP的工做過程的解說就結束了。總結一下:

UPnP分爲6個步驟:

先是Addressing,設備增長網絡,經過DHCP或者Auto-IP得到IP;這部分在閃聯IGRS中是未定義的。

而後是Discovery,採用SSDP協議(UDP),用multicast/unicast可以完畢設備的上線和離線通知和組播搜索設備,設備用unicast(單播,UDP)響應CP的搜索。

往下是Description,經過HTTP協議(TCP)取回來是一個XML文檔,包括物理描寫敘述和服務描寫敘述;

再來是Control,採用SOAP協議(HTTP/TCP),完畢CP和devices之間的交互;

Eventing,採用GENA協議(HTTP/TCP),完畢設備事件消息的訂閱和推送,爲保證可靠性,故是TCP傳輸;事件的推送還有multicast (UDP)。

最後是Presentation。UPnP並未定義Presentation應該有哪些東西。一個HTML嘛,哪樣寫得好哪樣來!

 

擴展閱讀II UPnP AV(Audio/Video) Architecture


1.概述

如下是解說UPnP AV的會用到的一些對象術語。

 

Table1-1:  Default Short Names for the AV Specifications

 

AV Specification Name

Short Name

AVTransport

AVT

ConnectionManager

CM

ContentDirectory

CD

MediaRenderer

MR

MediaServer

MS

RenderingControl

RCS

ScheduledRecording

SRS

 

 

       在UPnP AV Architecture:1 (Document Version: 1.1) 文檔最開始的是這樣介紹的UPnP AV的:

       本文檔描寫敘述了整體的UPnP AV 架構。該架構是UPnP AV設備和服務範例的基礎架構。

       該架構定義了 UPnP 控制端與 UPnP AV設備基本交互,並且與特定設備類型,媒體內容格式與傳輸協議無關。它支持如電視機,錄像機和 CD / DVD 播放機 / 本身主動點唱機,機頂盒,音響系統,MP3播放器,精巧圖像照相機,攝像機,電子相框,以及PC 等各類設備,。該AV 架構贊成設備支持不一樣格式的多媒體格式(如MPEG2 MPEG4 JPEG 格式, MP3 Windows 媒體架構( WMA ),位圖(BMP ), NTSC 制式, PAL 制式, ATSC標準等)和多種類型的傳輸協議,如 IEC-61883/IEEE-1394HTTP GET RTP 協議, HTTP PUT/郵政, TCP / IP 協議等)。下面各節描寫敘述了AV架構,以及怎樣各類UPnP AV設備和服務協同工做,使各類終於用戶的狀況。

         「與特定設備類型,媒體內容格式與傳輸協議無關」的內在含意是UPnP AV Architecture僅僅是提供了某種機制、模型,並無規定採用

何種技術來實現。技術的實現部分在  UPnP Device Architecture中有說明。

 

UPnP AV Architecture 定義了UPnP AV設備間媒體傳送以及和CP間的交互。 UPnP AV 也定義了兩種 UPnP AV 設備:UPnP AV MediaServer MS)和 UPnP AV MediaRenderMR ),以及他們具備的 4 種服務:

         1)Content Directory Service(CDS):能將可訪問的媒體內容列出。

         2)Connection Manager Service(CMS):決定媒體內容可以經過何種方式由UPnP AV Media Server傳送至 UPnP AV MediaRender

         3)AVTransport Service:控制媒體內容,比方播放、中止、暫停、查找等。

         4)Rendering Control Service:控制以何種方式播放內容,比方音量、靜音、亮度等。

 

2.UPnP AV 設備的交互模型

        在設備交互中, CP 是最重要的,因爲 Action 通常是由CP發出的。UPnP AV 架構對 CP 的功能要求有 10條:發現 AV設備,得到所需的內容列表,得到渲染器支持的協議/ 格式,比較/匹配協議 / 格式,配置server/渲染器,選擇所需的內容,開始內容傳輸,調整渲染參數,反覆:選擇下一個內容,斷開server和渲染器鏈接。

 

         CP可以是MediaServer,也可以是MediaRenderer,也可能僅僅是遙控器remote control。依據CP的角色,概括出如下三種常見的AV設備交互模型:

(1)2-Box Pull Model

 

這樣的狀況下CP是MediaRenderer,它可以是一個智能手機。CP主動向MediaServer索取媒體內容,得到內容以後播放媒體,是拉(pull)的方式。

CP要作的是 得到媒體列表>選取所需內容>匹配協議 / 格式,MediaServer需要  選取所需內容>匹配協議/格式>開始傳輸。


(2)2-Box Push Model

 


 

這樣的狀況下CP是MediaServer,它可以是一個一體機。CP主動向MediaRenderer推送(push)媒體。

CP要作的是 本地選取所需內容>匹配協議 / 格式>傳輸;MediaRenderer需要只需要 匹配協議/格式>接收媒體。

 

(3)3-box model

 

3-box model中,CP只做爲一個遙控器。也分爲pull和push兩種方式。

當pull方式時,CP向Renderer發送Server及Server上所需媒體內容的URL,讓Renderer去取;

當push方式時,CP向Server發Renderer的URL,讓Server去向Renderer推送媒體內容。

 

本文結束。

相關文章
相關標籤/搜索