基于DLNA实现iOS、Android投屏

MYBOYER

已于 2022-03-11 19:42:17 修改

阅读量4.6k

点赞数 3

分类专栏： android进阶文章标签： android ios 网络

于 2020-08-05 11:22:36 首次发布

本文链接：https://blog.csdn.net/MYBOYER/article/details/107810916

版权

由于我司需求，需要在iOS和安卓客户端实现DLNA投屏和控制。经过一番折腾，决定由我来研究DLNA。说起来又兴奋又紧张，兴奋希望自己能够弄出来然后跟安卓组讲解原理，紧张是因为怕自己能力不足做不出来。

DLNA网上的资料比较笼统不好入门，官方资料直接是每个1000多页的10几个PDF文档，根本无从下手。相关开源项目有名的有Platinum UPnP，但是由于它是基于C++实现的，相关文档并不全面。iOS相关开源项目都三四年没更新的，找来找去只好自己去啃自己去实现了。还好买到一本不错的书《智能家庭网络：技术、标准与应用实践》。通过近俩星期的研究，搞懂了DLNA核心协议UPnP基本逻辑，实现了投屏和控制功能的Demo。

下面就整理一下实现基本概念，实现过程和一些坑。

如果要直接看实现过程，请看以下三篇文章：

基础概念

DLNA

DLNA的全称是DIGITAL LIVING NETWORK ALLIANCE(数字生活网络联盟)，其宗旨是Enjoy your music, photos and videos, anywhere anytime， DLNA(Digital Living Network Alliance) 由索尼、英特尔、微软等发起成立、旨在解决个人PC，消费电器，移动设备在内的无线网络和有线网络的互联互通，使得数字媒体和内容服务的无限制的共享和增长成为可能，目前成员公司已达280多家。

DLNA标准包括多项协议及标准，其中最重要的部分是UPnP。对于我们目前的需求UPnP就能满足全部要求。

UPnP

通用即插即用（英语：Universal Plug and Play，简称UPnP）是由“通用即插即用论坛”（UPnP™ Forum）推广的一套网络协议。该协议的目标是使家庭网络（数据共享、通信和娱乐）和公司网络中的各种设备能够相互无缝连接，并简化相关网络的实现。UPnP通过定义和发布基于开放、因特网通讯网协议标准的UPnP设备控制协议来实现这一目标。

UPnP这个概念是从即插即用（Plug-and-play）派生而来的，即插即用是一种热拔插技术。

协议栈

UPnP设备体系结构包含了设备之间、控制点之间、设备和控制点之间的通信。完整的UPnP由设备寻址、设备发现、设备描述、设备控制、事件通知和基于Html的描述界面几部分构成。

UPnP协议栈

UPnP是一个多层协议构成的框架体系，每一层都以相邻的下层为基础，同时又是相邻上层的基础。直至达到应用层为止。该图中的最下面是就是IP和TCP，共两层，负责设备的IP地址。
三层是HTTP、HTTPU、HTTPMU，这一层，属于传送协议层。传送的是内容都经过“封装”后，存放在特定的XML文件中的。对应的SSDP、GENA、SOAP指的是保存在XML文件中的数据格式。到这一层，已经解决了UPnP设备的IP地址和传送信息问题。
第四层是UPnP设备体系定义，仅仅是一个抽象的、公用的设备模型。任何UPnP设备都必须使用这一层。
第五层是UPnP论坛的各个专业委员会的设备定义层，在这个论坛中，不同电器设备由不同的专业委员会定义，例如：电视委员会只负责定义网络电视设备部分，空调器委员会只负责定义网络空调设备部分，依此类推。所有的不同类型的设备都被定义成一个专门的架构或者模板，供建立设备的时候使用。可以推知，进入这一层，设备已经被指定了明确用途。当然，这些都必须遵守标准化的规范。从目前看，UPnP已经可以支持大部分的设备：从电脑、电脑外设，移动设备和家用消费类电子设备等等，无所不包，随着这个体系的普及，将可能有更多的厂家承认这一标准，最终，可能演化为公认的行业标准。
最上层，也就是应用层，由UPnP设备制造厂商定义的部分。这一层的信息是由设备制造厂商来“填充” 的，这部分一般有设备厂商提供的、对设备控制和操作的底层代码，然后，就是名称序列号呀，厂商信息之类的东西。

设备

设备是提供服务的网路实体，是一个逻辑概念，一个屋里设备可以包含一个或者多个逻辑设备。例如一台PC可以有两个逻辑设备———视频播放器和图片浏览器。

服务

服务是UPnP中最小的可控单元，它包括一系列可控制而动作和一组记录该服务目前情况的状态。服务是依赖于设备存在的。

控制点

控制UPnP设备工作的网络终端，主要功能包括获取设备描述和相关服务列表；获取感兴趣的服务描述；发出控制消息控制设备动作；向感兴趣的服务发出订阅消息，以便当服务状态改变时，自动获得时间通知。

UPnP组件

一些术语

UUID

UUID含义是通用唯一识别码（Universally Unique Identifier），其目的是让分布式系统中的所有元素，都有唯一的辨识资讯，而不需要透过中央控制端来做辨识资讯的指定。其格式为xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx(8-4-4-16),分别为当前日期和时间，时钟序列，全局唯一的IEEE机器识别号，如果有网卡，从网卡mac地址获得，没有网卡以其他方式获得。

单一设备名（Unique Device Name），基于UUID，表示一个设备。在不同的时间，对于同一个设备此值应该是唯一的。

Web上可用的每种资源 - HTML文档、图像、视频片段、程序等 - 由一个通用资源标志符（Universal Resource Identifier,简称”URI”）进行定位。 URI一般由三部分组成：访问资源的命名机制；存放资源的主机名；资源自身的名称，由路径表示。考虑下面的URI，它表示了当前的HTML 4.0规范：http://www.webmonkey.com.cn/html/html40/它表示一个可通过HTTP协议访问的资源，位于主机www.webmonkey.com.cn上，通过路径/html/html40访问。

URL是URI命名机制的一个子集，URL是Uniform Resource Location的缩写，译为“统一资源定位符”。通俗地说，URL是Internet上用来描述信息资源的字符串，主要用在各种www客户程序和服务器程序上。采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。

URN：URL的一种更新形式，统一资源名称(URN,Uniform Resource Name)。唯一标识一个实体的标识符，但是不能给出实体的位置。标识持久性Internet资源。URN可以提供一种机制，用于查找和检索定义特定命名空间的架构文件。尽管普通的URL可以提供类似的功能，但是在这方面，URN 更加强大并且更容易管理，因为 URN 可以引用多个 URL。

实现

工作机制

UPnP设备的发现和控制分为6个步骤：寻址、发现、描述、控制、事件及展现。

UPnP工作机制

这三点分别在后面的三篇文章中进行介绍。

整体流程

整体工作流程如下：

UPnP整体工作流程

参考

upnp协议简介（一）

基于DLNA实现iOS，Android投屏：SSDP发现设备

SSDP能够在局域网能简单地发现设备提供的服务。SSDP有两种发现方式：主动通知和搜索响应方式。

寻址

UPnP 技术是架构在 IP 网络之上。因此拥有一个网络中唯一的 IP 地址是 UPnP 设备正常工作的基础。UPnP 设备首先查看网络中是否有 DHCP 服务器，如果有，那么使用 DHCP 分配的 IP 即可；如果没有，则需要使用LLA技术来为自己找适合的IP地址。

另外，在 UPnP 运行过程中，UPnP 设备都需要周期性检测网络中是否有 DHCP 服务器存在，一旦发现有 DHCP 服务器，就必须终止使用 LLA 技术获取的 IP 地址，改用 DHCP 分配的 IP 地址。

发现

SSDP

SSDP:Simple Sever Discovery Protocol，简单服务发现协议，此协议为网络客户提供一种无需任何配置、管理和维护网络设备服务的机制。此协议采用基于通知和发现路由的多播发现方式实现。协议客户端在保留的多播地址：239.255.255.250：1900（IPV4）发现服务，（IPv6 是：FF0x::C）同时每个设备服务也在此地址上上监听服务发现请求。如果服务监听到的发现请求与此服务相匹配，此服务会使用单播方式响应。

常见的协议请求消息有两种类型，第一种是服务通知，设备和服务使用此类通知消息声明自己存在；第二种是查询请求，协议客户端用此请求查询某种类型的设备和服务。
iOS中使用GCDAsyncUdpSocket发送和接受SSDP请求、响应及通知，安卓也需要用类此框架来完成

所以我们发现设备也有两种方法

主动通知方式：当设备加入到网络中，向网络上所有控制点通知它所提供的服务，通知消息采用多播方式。
搜索——响应方式：当一个控制点加入到网络中，在网络搜索它感兴趣的所有设备和服务，搜索消息采用多播方式发送，而设备针对搜索的响应则是使用单播方式发送。

SSDP 设备类型及服务类型

设备类型	表示文字
UPnP_RootDevice	upnp:rootdevice
UPnP_InternetGatewayDevice1	urn:schemas-upnp-org:device:InternetGatewayDevice:1
UPnP_WANConnectionDevice1	urn:schemas-upnp-org:device:WANConnectionDevice:1
UPnP_WANDevice1	urn:schemas-upnp-org:device:WANConnectionDevice:1
UPnP_WANCommonInterfaceConfig1	urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
UPnP_WANIPConnection1	urn:schemas-upnp-org:device:WANConnectionDevice:1
UPnP_Layer3Forwarding1	urn:schemas-upnp-org:service:WANIPConnection:1
UPnP_WANConnectionDevice1	urn:schemas-upnp-org:service:Layer3Forwarding:1

服务类型	表示文字
UPnP_MediaServer1	urn:schemas-upnp-org:device:MediaServer:1
UPnP_MediaRenderer1	urn:schemas-upnp-org:device:MediaRenderer:1
UPnP_ContentDirectory1	urn:schemas-upnp-org:service:ContentDirectory:1
UPnP_RenderingControl1	urn:schemas-upnp-org:service:RenderingControl:1
UPnP_ConnectionManager1	urn:schemas-upnp-org:service:ConnectionManager:1
UPnP_AVTransport1	urn:schemas-upnp-org:service:AVTransport:1

主动通知方式

当设备添加到网络后，定期向（239.255.255.250:1900）发送SSDP通知消息宣告自己的设备和服务。

宣告消息分为 ssdp:alive(设备可用) 和 ssdp:byebye(设备不可用)

ssdp:alive 消息

NOTIFY * HTTP/1.1           // 消息头
NT:                         // 在此消息中，NT头必须为服务的服务类型。（如：upnp:rootdevice）
HOST:                       // 设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4）或FF0x::C(IPv6
NTS:                        // 表示通知消息的子类型，必须为ssdp:alive
LOCATION:                   // 包含根设备描述得URL地址  device 的webservice路径（如：http://127.0.0.1:2351/1.xml) 
CACHE-CONTROL:              // max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在 （如：max-age=1800）
SERVER:                     // 包含操作系统名，版本，产品名和产品版本信息( 如：Windows NT/5.0, UPnP/1.0)
USN:                        // 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。如：
                            // 根/启动设备 uuid:f7001351-cf4f-4edd-b3df-4b04792d0e8a::upnp:rootdevice
                            // 连接管理器  uuid:f7001351-cf4f-4edd-b3df-4b04792d0e8a::urn:schemas-upnp-org:service:ConnectionManager:1
                            // 内容管理器 uuid:f7001351-cf4f-4edd-b3df-4b04792d0e8a::urn:schemas-upnp-org:service:ContentDirectory:1

ssdp:byebye 消息

当设备即将从网络中退出时，设备需要对每一个未超期的 ssdp:alive 消息多播形式发送 ssdp:byebye 消息，其格式如下：

NOTIFY * HTTP/1.1       // 消息头
HOST:                   // 设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4）或FF0x::C(IPv6
NTS:                    // 表示通知消息的子类型，必须为ssdp:byebye
USN:                    // 同上

搜索——响应方式

当控制点，如手机客户端，加入到网络中，可以通过多播搜索消息来寻找网络上感兴趣的设备。我写DLNA模块时候也用主动搜索方式来发现设备。主动搜索可以使用多播方式在整个网络上搜索设备和服务，也可以使用单播方式搜索特定主机上的设备和服务。

多播搜索消息

一般情况我们使用多播搜索消息来搜索所有设备即可。多播搜索消息如下：

M-SEARCH * HTTP/1.1             // 请求头 不可改变
MAN: "ssdp:discover"            // 设置协议查询的类型，必须是：ssdp:discover
MX: 5                           // 设置设备响应最长等待时间，设备响应在0和这个值之间随机选择响应延迟的值。这样可以为控制点响应平衡网络负载。
HOST: 239.255.255.250:1900      // 设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4）或FF0x::C(IPv6
ST: upnp:rootdevice             // 设置服务查询的目标，它必须是下面的类型：
                                // ssdp:all  搜索所有设备和服务 
                                // upnp:rootdevice  仅搜索网络中的根设备 
                                // uuid:device-UUID  查询UUID标识的设备 
                                // urn:schemas-upnp-org:device:device-Type:version  查询device-Type字段指定的设备类型，设备类型和版本由UPNP组织定义。 
                                // urn:schemas-upnp-org:service:service-Type:version  查询service-Type字段指定的服务类型，服务类型和版本由UPNP组织定义。

如果需要实现投屏，则设备类型 ST 为 urn:schemas-upnp-org:service:AVTransport:1

多播搜索响应

多播搜索 M-SEARCH 响应与通知消息很类此，只是将NT字段作为ST字段。响应必须以一下格式发送：

HTTP/1.1 200 OK             // * 消息头
LOCATION:                   // * 包含根设备描述得URL地址  device 的webservice路径（如：http://127.0.0.1:2351/1.xml) 
CACHE-CONTROL:              // * max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在 （如：max-age=1800）
SERVER:                     // 包含操作系统名，版本，产品名和产品版本信息( 如：Windows NT/5.0, UPnP/1.0)
EXT:                        // 为了符合HTTP协议要求，并未使用。
BOOTID.UPNP.ORG:            // 可以不存在，初始值为时间戳，每当设备重启并加入到网络时+1，用于判断设备是否重启。也可以用于区分多宿主设备。
CONFIGID.UPNP.ORG:          // 可以不存在，由两部分组成的非负十六进制整数，由两部分组成，第一部分代表跟设备和其上的嵌入式设备，第二部分代表这些设备上的服务。
USN:                        // * 表示不同服务的统一服务名
ST:                         // * 服务的服务类型
DATE:                       // 响应生成时间

其中主要关注带有 * 的部分即可。这里还有一个大坑，有些设备返回来的字段名称可能包含有小写，如LOCATION和Location，需要做处理。
此外还需根据LOCATION保存设备的IP和端口地址。
响应例子如下：

HTTP/1.1 200 OK
Cache-control: max-age=1800
Usn: uuid:88024158-a0e8-2dd5-ffff-ffffc7831a22::urn:schemas-upnp-org:service:AVTransport:1
Location: http://192.168.1.243:46201/dev/88024158-a0e8-2dd5-ffff-ffffc7831a22/desc.xml
Server: Linux/3.10.33 UPnP/1.0 Teleal-Cling/1.0
Date: Tue, 01 Mar 2016 08:47:42 GMT+00:00
Ext: 
St: urn:schemas-upnp-org:service:AVTransport:1

描述

控制点发现设备之后仍然对设备知之甚少，仅能知道UPnP类型，UUID和设备描述URL。为了进一步了解设备和服务，需要获取并解析XML描述文件。
描述文件有两种类型：设备描述文档(DDD)和服务描述文档(SDD)

设备描述文档

设备描述文档是对设备的基本信息描述，包括厂商制造商信息、设备信息、设备所包含服务基本信息等。

设备描述采用XML格式，可以通过HTTP GET请求获取。其链接为设备发现消息中的Location。如上述设备的描述文件获取请求为

1
2

GET http://192.168.1.243:46201/dev/88024158-a0e8-2dd5-ffff-ffffc7831a22/desc.xml HTTP/1.1
HOST: 192.168.1.243:46201

设备响应如下

最低0.47元/天解锁文章

MYBOYER

关注

3
点赞
踩
21

收藏

觉得还不错? 一键收藏
0
评论
基于DLNA实现iOS、Android投屏

由于我司需求，需要在iOS和安卓客户端实现DLNA投屏和控制。经过一番折腾，决定由我来研究DLNA。说起来又兴奋又紧张，兴奋希望自己能够弄出来然后跟安卓组讲解原理，紧张是因为怕自己能力不足做不出来。DLNA网上的资料比较笼统不好入门，官方资料直接是每个1000多页的10几个PDF文档，根本无从下手。相关开源项目有名的有Platinum UPnP，但是由于它是基于C++实现的，相关文档并不全面。iOS相关开源项目都三四年没更新的，找来找去只好自己去啃自己去实现了。还好买到一本不错的书《智能家庭网络：技术、
复制链接

扫一扫