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