基于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请求、响应及通知,安卓也需要用类此框架来完成

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

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

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 消息

ssdp:byebye 消息

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

搜索——响应方式

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

多播搜索消息

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

如果需要实现投屏,则设备类型 STurn:schemas-upnp-org:service:AVTransport:1

多播搜索响应

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

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

描述

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

设备描述文档

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

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

设备响应如下

其中响应消息体为XML格式的设备描述内容。信息结构比较明确,就不一一介绍了。解析该XML,保存设备的一些基本信息如 deviceTypefriendlyNameiconList 等。之后我们关注该设备提供的服务列表,投屏最关注的服务为 urn:schemas-upnp-org:service:AVTransport:1:

如只需要实现简单的投屏,则保存urn:schemas-upnp-org:service:AVTransport:1服务的上述信息即可。如需要进一步了解该服务,则需要获取并解析服务描述文档。

坑点1:有些设备 SCPDURLcontrolURLeventSubURL 开头包含 / ,有些设备不包含,拼接URL时需要注意。

服务描述文档

为了实现简单的投屏和控制(播放、暂停、停止、快进)操作并不需要解析服务描述文件。所有动作均为UPnP规范动作,具体动作请求参见基于DLNA实现iOS,Android投屏:SOAP控制设备

服务描述文档是对服务功能的基本说明,包括服务上的动作及参数,还有状态变量和其数据类型、取值范围等。

和设备描述文档一致,服务描述文档也是采用XML语法,并遵守标准UPnP服务schema文件格式要求。获取上述服务SDD语法如下:

设备响应如下:

  • actionList 目前服务上所包含的动作列表。
  • actionList 目前服务上所包含的状态变量。

以Pause动作为例

为了实现简单的投屏和控制(播放、暂停、停止、快进)操作并不需要解析服务描述文件。所有动作均为UPnP规范动作,具体动作请求参见基于DLNA实现iOS,Android投屏:SOAP控制设备

1 2 收藏 评论

关于作者:BrikerMan

简介还没来得及写 :) 个人主页 · 我的文章

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部