DLNA 是什么

DLNA 的全稱是 Digital Living Network Alliance (數字生活網絡聯盟)，其宗旨是 Enjoy your music, photos and videos, anywhere anytime. DLNA 由索尼、英特爾、微軟等發起成立、旨在解決個人PC，消費電器，移動設備在內的無線網絡和有線網絡的互聯互通，使得數字媒體和內容服務的無限制的共享和增長成為可能，目前成員公司已達280多家。
DLNA 并不是創造技術，而是形成一種解決的方案，一種大家可以遵守的規范。所以，其選擇的各種技術和協議都是當前所應用很廣泛的技術和協議。

Tips：DLNA 意在解決PC，家電，移動設備在 局域網內 的多媒體（音頻，視頻，圖片）共享。

DLNA 中的設備類型

• Home Network Devices（家庭網絡設備）

1. DMS(Digital Media Server) 即數字媒體服務器，存儲，提供媒體內容，為 DMP 或 DMR 所用，比如PC電腦。
2. DMR(Digital Media Render) 即數字媒體渲染器，被動播放 DMS 上的內容，只能播放 DMC 推送過來的內容，比如TV。
3. DMC(Digital Media Controller) 即數字媒體控制器，查找 DMS 的內容，建立 DMS 與 DMR 之間的連接并控制媒體的播放，如智能手機，平板電腦等。
4. DMP(Digital Media Player) 即數字媒體播放器，能從 DMS 上查找并獲取媒體內容并播放和渲染顯示。比如TV、家庭劇院等。

• Mobile Handheld Devices（移動手持設備）

1. M-DMS(Mobile Digital Media Server) 存儲，提供媒體內容，為 M-DMP 或 DMR 所用，比如移動手機，隨身音樂播放器。
2. M-DMP(Mobile Digital Media Player) 能從 DMS 或 M-DMS上查找并獲取媒體內容并播放和渲染顯示，比如移動手機。
3. M-DMU(Mobile Digital Media Uploader) 向 DMS 或 M-DMS 上傳內容，比如數碼相機，移動手機。
4. M-DMD(Mobile Digital Media Downloader) 從 DMS 或 M-DMS 下載內容，比如移動手機，隨身音樂播放器。
5. M-DMC(Mobile Digital Media Controller) 發現 DMS 或 M-DMS上的內容，并發送至 DMR 。比如 PDA，移動手機。

DLNA 的這幾種設備類型中，DMS 跟 DMC 比較好理解，一個相當于對外提供內容的服務器，一個相當于遠程操控多屏設備的遙控器。而 DMP 跟 DMR 的區別主要是 DMR 是被動地接受別人的推送來播放，而 DMP 是發現別人的視頻并播放。

一般移動端產品上的多屏 SDK，實現的功能主要是 DMC 跟 DMP，當然也可以同時實現 DMS 功能（對外發布資源，別人主動發現你的資源 ）。

關于設備分類可以直接閱讀：
wikipedia Digital Living Network Alliance
或者：https://spirespark.com/dlna/guidelines

DLNA 的架構

dlna-arc.png

從下往上依次介紹：

1. NetWorking Connectivity

網絡互聯方式：包括物理連接的標準，有有線的，比如符合IEEE802.3標準的Ethernet；有無線的，比如符合IEEE802.11a/g標準的WiFi等。

2. NetWorking Stack

網絡協議棧：DLNA 的網絡協議包括 IPv4 和 IPv6，目前對IPv4的支持的比較好，IPv6后續也會支持起來的。

3. Device Discovery&Control

設備的發現跟控制是DLNA的基礎協議框架層，是DLNA非常重要的一層。DLNA用UPnP協議來實現設備的發現和控制，關于UPnP 下面會專門進行介紹。

4. Media Management

媒體管理包括媒體內容的識別、管理和分發。UPnP Audio/Video (AV) 技術用來解決 DLNA 設備的多媒體管理。稍后在 UPnP 環節會講述。

5. Remote UI

遠程用戶接口主要定義了網絡設備之間的UI 內容是如何被描述，格式化及傳輸的，也包括不同設備之間的事件發送機制及UI 更新機制。

6. Media Transport

媒體傳輸：這一層用HTTP( HyperText Transfer Protocol )超文本傳輸協議。就是平時我們上網用的媒體傳輸協議。HTTP 用 TCP 可靠傳輸，也有混合UDP 方式的 HTTP。現在 HTTP 的版本是 HTTP1.1，可選協議是 RTP。

7. Media Formats

媒體格式：圖片，音頻，視頻

UPnP 原理

UPnP(Universal Plug and Play) 即通用即插即用，是由“通用即插即用論壇”（UPnP Forum）推廣的一套網絡協議。該協議的目標是使家庭網絡（數據共享、通信和娛樂）和公司網絡中的各種設備能夠相互無縫連接，并簡化相關網絡的實現。UPnP通過定義和發布基于開放、因特網通訊網協議標準的UPnP設備控制協議來實現這一目標。

1. UPnP AV(Audio/Video) Architecture

在 UPnP 網絡中，服務、設備和控制點（Control Point，即 CP）是基本組件。UPnP網絡中定義的設備具有很廣泛的含義，各種各樣的家電、電腦外設、智能設備、無線設備、個人電腦等等都可以成為其中一員。一個UPnP設備可以是多個服務的載體和多個子設備的嵌套集。而控制點CP 指的是可以發現并控制其它設備的設備。

UPnP 網絡中的設備可提供四種服務（Service）：

1. AVTransport Service （可控制多屏設備上的媒體play，pause，seek，stop等）
2. RenderingControl Service （可調節多屏設備上的音量，聲音，靜音等）
3. ContentDirectory Service （可獲取多屏設備上可訪問的媒體內容）
4. ConnectionManager Service （可提供所支持的傳輸協議信息及多屏設備的MIME格式信息）

UPnP AV Architecture 定義了UPnP AV設備間媒體傳送以及和CP間的交互。UPnP AV也定義了兩種UPnP AV設備：UPnP AV MediaServer Device（MSD）和UPnP AV MediaRenderer Device（MRD）, 其中MSD至少包含ContentDirectory和ConnectionManager兩種服務；MRD則至少包含RenderingControl和ConnectionManager兩種服務。

2. UPnP 的工作過程

1. 尋址( Addressing )
   IP 尋址是整個UPnP網絡的基礎。設備或控制點必須支持 IPv4（或者是IPv4 和 IPv6）。當設備或 CP首次與網絡建立連接時，
   設備或控制點會尋找 DHCP（Dynamic Host Configuration Protocol）服務器，由 DHCP 負責分配向他們分配 IP。如果局域網內沒有 DHCP 服務，UPnP 設備將按照 Auto-IP 去獲取一個未被使用的 IP 地址。

2. 發現( Discovery )
   發現是 UPnP 網絡工作的第一步。 當一個設備加入到網絡中，UPnP 的發現協議允許該設備向網絡上的 Control Points(CPs)通知(advise)自己擁有的服務。類似地，當一個控制點加入到網絡中的時候，它也能夠搜索到網絡中存在的、感興趣的設備。設備主動通知或者被動響應時提供的信息僅包含少量的設備信息，比如，類型、uuid和指向更詳細信息的URL。Discovery architecture 如下圖所示：

Discovery.png

UPnP 檢測協議是基于簡單服務發現協議（SSDP，Simple Service Discovery Protocol）的。

按照協議的規定，當一個控制點（CP）接入網絡的時候，它可以向一個特定的多播地址的 SSDP 端口( 比如IPv4環境下，多播地址是239.255.255.250，端口號是1900 )使用M-SEARCH方法發送“ssdp:discover”消息。當設備監聽到這個保留的多播地址上由控制點發送的消息的時候，設備會分析控制點請求的服務，如果自身提供了控制點請求的服務，設備將通過單播的方式直接響應控制點的請求。類似的，當一個設備接入網絡的時候，它應當向一個特定的多播地址的 SSDP 端口使用 NOTIFY 方法發送“ssdp:alive”消息。控制點根據自己的策略，處理監聽到的消息。

SSDP 格式套用 HTTP1.1 的部分消息頭字段，但是和 HTTP 不同，SSDP是采用UDP傳輸的，而且SSDP沒有 Message Body。
下面說明設備怎樣向網絡通知或者撤銷自己可以提供的服務，CP 是如何搜索設備以及設備是如何回應搜索的。

• 通知-設備可用
  當一個設備加入網絡時，用 NOTIFY 方法發送一個多播請求，并且 NTS 頭為 ssdp:alive 。NOTIFY 方法發送的請求沒有消息體，但消息與最后一個 HTTP 頭之間必須空一行。
  ssdp:alive 消息格式：

ssdp:alive 消息格式.png

NOTIFY 消息必須包含以下四部分：
a. A notification type (e.g., device type), sent in an NT (Notification Type) header field.
b. A composite identifier for the advertisement, sent in a USN (Unique Service Name) header field.
c. A URL for more information about the device (or enclosing device in the case of a service), sent in a LOCATION header field.
d. A duration for which the advertisement is valid, sent in a CACHE-CONTROL header field. （單位：秒）

• 撤銷-設備不可用
  在設備及其服務將要從網絡中退出時，設備以多播方式用 NOTIFY 方法發送 ssdp:byebye 消息( 對于每個未超期的ssdp:alive消息 )。但如果設備突然從網絡退出，它可能來不及發出這個通知消息。因此，discovery message 必須在CACHE-CONTROL 中包含超時值（如上所述）；如果不重新發出通告，discovery message 最后也會因超時而過期的。
  ssdp:byebye 消息格式如下：

ssdp:byebye 消息格式.png

• 搜索
  當一個控制點加入到網絡中時，它應該采用以下格式的 M-SEARCH 方法發送多播請求來搜索自己感興趣的設備（服務）。如果 CP 已知道設備的IP，也可以類似的格式發送單播去了解詳細信息。

搜索.png

• 響應
  當設備自身能夠提供與 CP 發出的多播消息所匹配的服務時，就會以單播形式予以響應，消息格式如下：

響應.png

需要注意的是：設備通過主動多播方式或者是被動地響應 CP 的搜索消息，使得 CP 能夠了解到它是否是自己感興趣的設備。但是如果 CP 對某設備感興趣，想獲取更多信息的話，則需要通過已獲得的“指向更詳細信息的URL”來發送description query message，從而得到設備詳細的描述信息。

3. 描述( Description )
   在控制點發現了一個設備之后，控制點仍然對設備知之甚少。可能僅僅知道發現消息中的相關信息，如設備（或服務）的UPnP類型、設備的全球唯一標識符和設備UPnP描述的URL地址。為了讓控制點更多的了解設備及其功能、或者與設備交互，控制點必須從發現消息中得到設備描述的URL，并通過URL取得詳細的設備描述。這些信息是以 XML 的形式返回的。
   設備的UPnP描述一般分成兩個邏輯部分：設備描述以及服務描述（描述設備對外暴露的能力）。

• 設備描述
  UPnP設備描述包括特定廠商、制造商信息，如模塊名稱和編號、序列號、制造商名稱、特定廠商網站 URL 等。對于設備中的每種服務，描述包含服務類型、名稱、服務描述URL、控制URL以及事件URL。設備描述還包括所有嵌入式設備描述及presentationURL.

• 服務描述
  關于服務的UPnP描述定義了 Action 及其參數，還有狀態變量及其數據類型、取值范圍和事件特征。
  每個服務必須包含 0 或多個Action，每個Action必須包含 0 或多個參數，每個參數要么是輸入參數要么是輸出參數，每個參數對應一個狀態變量，每個服務有 1 或多個狀態變量。

XML 格式如下：

Description.png

獲取設備描述很簡單，CP 向discovery message 里的URL 發一個HTTP GET 請求，設備在HTTP響應的消息體中返回其描述。

4. 控制( Control )
   拿到 Device description 和 Service descriptions 以后，那 CP 怎么去控制這些設備呢？
   為了控制一個設備，控制點向設備上的服務發出一個 Action 。這一般由控制點向服務的controLURL（在設備描述的服務元素controlURL子元素部分提供）發送一個適當的控制消息。而服務則會對此 Action 做出響應，返回相關結果或錯誤。

UPnP 的設備控制是基于 SOAP 協議的，SOAP（Simple Object Access Protocol）即簡單對象訪問協議，是交換數據的一種協議規范，是一種輕量的、簡單的、基于XML（標準通用標記語言下的一個子集）的協議，它被設計成在WEB上交換結構化的和固化的信息。在 UPnP 中控制點會向設備的服務發出 Action，并接收結果或錯誤返回，該動作、結果和錯誤封裝在SOAP中，通過HTTP 請求發送，并通過 HTTP 響應接收。

5. 事件( Eventing )

控制點可以監聽設備的狀態，設備的狀態或信息發生了變化，只要產生一個事件廣播出去，控制點就能接收到并進行響應，類似一般的訂閱者模式，發布者是指事件源即設備的服務，訂閱者是控制點。
有兩種類型的事件：單播事件和多播事件。

• 單播事件

單播事件架構.png

• 多播事件

多播事件架構.png

6. 表示/展示( Presentation )

控制點發現設備并且獲取到設備的描述信息后，如果設備有返回 "presentationURL" ，那么，控制點就可以請求（HTTP GET）該 URL，在瀏覽器中展示出來，用戶通過該網頁就能控制遠端的設備，或查看設備狀態等。

Presentation.png

以上UPnP 的工作過程每一個步驟詳細可見：http://trinea.github.io/doc/upnp/UPnP-arch-DeviceArchitecture-v1.1.pdf

DLNA 與 UPnP 的關系

具體可參考這篇文章，http://blog.51cto.com/ticktick/1637257