minidlna源码初探（二）—— SSDP设备发现的大致流程

前言：

之前有专文介绍了minidlna中的UPNP功能，内中介绍其中包含的SSDP（简单发现协议），SOAP（简单对象访问协议）等几个协议（http://blog.csdn.net/sakaue/article/details/19070735）。本文将根据minidlna的程序流程，概述SSDP的流程，为下一部分ACE实现做铺垫。

设备发现的大致流程：

首先，根据UPNP的规范：

在设备加入网络，UPnP发现协议允许设备向控制点广告它的服务。它使用向一个标准地址和端口多址传送发现消息来实现。控制点在此端口上侦听是否有新服务加入系统。为了通知所有设备，一个设备为每个其上的嵌入设备和服务发送一系列相应的发现消息。每个消息也包含它表征设备或服务的特定信息。

我们需要在服务（设备）开始时定时多播一个ssdp::alive给各个加入组播的用户（控制点），信息个格式如下：

    NOTIFY * HTTP/1.1
    HOST:239.255.255.250:1900                                    #协议保留多播地址和端口，必须是239.255.255.250:1900
    CACHE-CONTROL:max-age=1810                           #max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在
    LOCATION:http://192.168.1.20:8200/rootDesc.xml     #包含根设备描述得URL地址
    SERVER: 3.4.72-rt89 DLNADOC/1.50 UPnP/1.0 SakaueDLNA/1.1.0
    NT:upnp:rootdevice   #在此消息中，NT头必须为服务的服务类型
    USN:uuid:4d696e69-444c-164e-9d41-001ec92f0378::upnp:rootdevice   #表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力
    NTS:ssdp:alive   #表示通知消息的子类型，必须为ssdp:alive

这种定时的的ssdp::alive消息需要发送以下几种类型的USN（统一服务名）：

static const char * const known_service_types[] =
{
    "upnp:rootdevice",                                                              //网络中的根设备
    "urn:schemas-upnp-org:device:MediaServer:",                      //媒体服务器
	"urn:schemas-upnp-org:service:ContentDirectory:",               //内容管理服务
	"urn:schemas-upnp-org:service:ConnectionManager:",          //连接管理服务
	"urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:",
	0
};

其次

当一个控制点加入到网络中时，设备发现过程允许控制点寻找网络上感兴趣的设备。发现消息包括设备的一些特定信息或者某项服务的信息，例如它的类型、标识符、和指向XML设备描述文档的指针。从设备获得响应从本质上说，内容与多址传送的设备广播相同，只是采用单址传送方式。设备查询通过HTTP协议扩展M-SEARCH方法实现的。

客户端（接入点）接入网络后，会通过组播方式回传给服务端（设备）ssdp:discover消息，在这里，我们使用VLC作为客户端（接入点）。其格式如下：

M-SEARCH * HTTP/1.1
Host: 239.255.255.250:1900  #设置为协议保留多播地址和端口，必须是239.255.255.250:1900。
Man: "ssdp:discover"           #设置协议查询的类型，必须是"ssdp:discover"。
MX: 5                                 #设置设备响应最长等待时间，设备响应在0和这个值之间随机选择响应延迟的值。这样可以为控制点响应平衡网络负载。
ST: upnp:rootdevice             #设置服务查询的目标

在设备接收到查询请求并且查询类型（ST字段值）与此设备匹配时，设备必须向多播地址239.255.255.250:1900回应响应消息，其格式如下：

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1810
DATE: Wed, 21 May 2014 03:54:53 GMT         #指定响应生成的时间
ST: urn:schemas-upnp-org:device:MediaServer:1                              #内容和意义与查询请求的相应字段相同
USN: uuid:4d696e69-444c-164e-9d41-001ec92f0378::urn:schemas-upnp-org:device:MediaServer:1  #表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。
EXT:                                                                                              #向控制点确认MAN头域已经被设备理解
SERVER: 3.2.0-61-generic DLNADOC/1.50 UPnP/1.0 SakaueDLNA/1.1.2   #饱含操作系统名，版本，产品名和产品版本信息
LOCATION: http://192.168.1.20:8200/rootDesc.xml                            #包含根设备描述得URL地址
Content-Length: 0

一切顺利的话，我们会在8200的监控端口收到客户端的单址讯息，其格式如下：

GET /rootDesc.xml HTTP/1.1
HOST: 192.168.1.20:8200
DATE: Wed, 28 May 2014 05:15:02 GMT
CONNECTION: close
USER-AGENT: 6.1.7600 2/, UPnP/1.0, Portable SDK for UPnP devices/1.6.14

收到该讯息后，我们需要向客户端会送（单址）一则服务端（设备）的根信息，其格式如下：

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Connection: close
Content-Length: 2189
Server: 3.2.0-61-generic DLNADOC/1.50 UPnP/1.0 SakaueDLNA/1.1.2
Date: Thu, 22 May 2014 05:29:30 GMT
EXT:

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
    <specVersion>
        <major>1</major>
        <minor>0</minor>
    </specVersion>
    <device>
        <deviceType>urn:schemas-upnp-org:device:MediaServer:1</deviceType>
        <friendlyName>Jane</friendlyName>
        <manufacturer>Justin Maggard</manufacturer>
        <manufacturerURL>http://www.netgear.com/</manufacturerURL>
        <modelDescription>SakaueDLNA on Linux</modelDescription>
        <modelName>Windows Media Connect compatible (SakaueDLNA)</modelName>
        <modelNumber>1</modelNumber>
        <modelURL>http://www.netgear.com</modelURL>
        <serialNumber>12345678</serialNumber>
        <UDN>uuid:4d696e69-444c-164e-9d41-001ec92f0378</UDN>
        <dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0">DMS-1.50</dlna:X_DLNADOC>
        <presentationURL>/</presentationURL>
        <iconList>
            <icon>
                <mimetype>image/png</mimetype>
                <width>48</width>
                <height>48</height>
                <depth>24</depth>
                <url>/icons/sm.png</url>
            </icon>
            <icon>
                <mimetype>image/png</mimetype>
                <width>120</width>
                <height>120</height>
                <depth>24</depth>
                <url>/icons/lrg.png</url>
            </icon>
            <icon>
                <mimetype>image/jpeg</mimetype>
                <width>48</width>
                <height>48</height>
                <depth>24</depth>
                <url>/icons/sm.jpg</url>
            </icon>
            <icon>
                <mimetype>image/jpeg</mimetype>
                <width>120</width>
                <height>120</height>
                <depth>24</depth>
                <url>/icons/lrg.jpg</url>
            </icon>
        </iconList>
        <serviceList>
            <service>
                <serviceType>urn:schemas-upnp-org:service:ContentDirectory:1</serviceType>
                <serviceId>urn:upnp-org:serviceId:ContentDirectory</serviceId>
                <controlURL>/ctl/ContentDir</controlURL>
                <eventSubURL>/evt/ContentDir</eventSubURL>
                <SCPDURL>/ContentDir.xml</SCPDURL>
            </service>
            <service>
                <serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>
                <serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>
                <controlURL>/ctl/ConnectionMgr</controlURL>
                <eventSubURL>/evt/ConnectionMgr</eventSubURL>
                <SCPDURL>/ConnectionMgr.xml</SCPDURL>
            </service>
            <service>
                <serviceType>urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:1</serviceType>
                <serviceId>urn:microsoft.com:serviceId:X_MS_MediaReceiverRegistrar</serviceId>
                <controlURL>/ctl/X_MS_MediaReceiverRegistrar</controlURL>
                <eventSubURL>/evt/X_MS_MediaReceiverRegistrar</eventSubURL>
                <SCPDURL>/X_MS_MediaReceiverRegistrar.xml</SCPDURL>
            </service>
        </serviceList>
    </device>
</root>   

在VLC的“本地网络”->"通用即插即播"下应该能看到我们的设备，这里的设备名（friendlyName）叫Jane。

minidlna源码初探（二）—— SSDP设备发现的大致流程,布布扣,bubuko.com

时间： 2024-10-27 01:57:12

minidlna源码初探（二）—— SSDP设备发现的大致流程的相关文章

可视化工具gephi源码探秘(二)---导入netbeans

在上篇<可视化工具gephi源码探秘(一)>中主要介绍了如何将gephi的源码导入myeclipse中遇到的一些问题,此篇接着上篇而来,主要讲解当下通过myeclipse导入gephi源码的可行性不高以及熟悉netbeans,并把原本基于netbeans平台开发的gephi源码导入进netbeans后启动正常运行的过程,其中有遇到的不少问题和相应的解决方法. 前日工作梗概(还是沿着想把源码导入myeclipse的思路): 经过从各大子模块的pom.xml中筛选出符合条件的jar包写入项目下的p

cocos2d-x 委托模式的巧妙运用——附源码（二）

转载请注明出处:http://blog.csdn.net/hust_superman/article/details/38292265,谢谢. 继上一篇将了委托类的具体实现后,这篇来将一下如何在游戏中使用实现的委托类.也就是如何在游戏中来调用委托类来完成一些功能.具体的应用场景和应用层会在下面介绍. 先来看一看游戏demo实现的具体图片,demo比较简单,但是资源齐全,拿到源码后可以在源码的基础上继续完善demo做出一款真正的游戏.好了,老规矩,先上图再说: 游戏中点击播放按钮后会进入游戏主界面

NoHttp和OkHttp的无缝结合 NoHttp框架作者带你看源码（二）

NoHttp和OkHttp的无缝结合 NoHttp框架作者带你看源码(二) 版权声明:转载必须注明本文转自严振杰的博客: http://blog.csdn.net/yanzhenjie1003 上一次带大家分析了NoHttp源码,知道我们可以替换NoHttp的底层为其他任何库,例如OkHttp.HttpURLConnection.HttpClient,那今天就带领大家一步步来实现替换NoHttp的底层为OkHttp. NoHttp源码分析的博客:http://blog.csdn.net/yanz

netty 源码分析二

以服务端启动,接收客户端连接整个过程为例分析, 简略分为 五个过程: 1.NioServerSocketChannel 管道生成, 2.NioServerSocketChannel 管道完成初始化, 3.NioServerSocketChannel注册至Selector选择器, 4.NioServerSocketChannel管道绑定到指定端口,启动服务 5.NioServerSocketChannel接受客户端的连接,进行相应IO操作 Ps:netty内部过程远比这复杂,简略记录下方便以后回忆

[Android]Volley源码分析(二)Cache

Cache作为Volley最为核心的一部分,Volley花了重彩来实现它.本章我们顺着Volley的源码思路往下,来看下Volley对Cache的处理逻辑. 我们回想一下昨天的简单代码,我们的入口是从构造一个Request队列开始的,而我们并不直接调用new来构造,而是将控制权反转给Volley这个静态工厂来构造. com.android.volley.toolbox.Volley: public static RequestQueue newRequestQueue(Context conte

哇！板球 源码分析二

游戏主页面布局 创建屏下Score标签 pLabel = CCLabelTTF::create("Score", "Arial", TITLE_FONT_SIZE); //分数标签 //设置标签字体的颜色 pLabel->setColor (ccc3(0, 0, 0)); //设置文本标签的位置 pLabel->setPosition ( ccp ( SCORE_X, //X坐标 SCORE_Y //Y坐标 ) ); //将文本标签添加到布景中 this

Spring 源码解析之HandlerAdapter源码解析(二)

Spring 源码解析之HandlerAdapter源码解析(二) 前言 看这篇之前需要有Spring 源码解析之HandlerMapping源码解析(一)这篇的基础,这篇主要是把请求流程中的调用controller流程单独拿出来了 解决上篇文章遗留的问题 getHandler(processedRequest) 这个方法是如何查找到对应处理的HandlerExecutionChain和HandlerMapping的,比如说静态资源的处理和请求的处理肯定是不同的HandlerMapping ge

baksmali和smali源码分析(二)

这一节,主要介绍一下 baksmali代码的框架. 我们经常在反编译android apk包的时候使用apktool这个工具,其实本身这个工具里面对于dex文件解析和重新生成就是使用的baksmali 和smali这两个jar包其中 baksmali是将 dex文件转换成便于阅读的smali文件的,具体使用命令如下:java -jar baksmali.jar classes.dex -o myout其中myout是输出的文件夹 而smali是将smali文件重新生成回 dex文件的具体使用的命

【梦幻连连连】源码分析(二)

转载请注明出处:http://blog.csdn.net/oyangyufu/article/details/24736711 GameLayer场景界面效果: 源码分析: GameLayer场景初始化,主要是初始化加载界面及背景音乐 bool GameLayer::init() { float dt=0.0f; if ( !CCLayerColor::initWithColor(ccc4(255, 255, 255, 255))) { return false; } this->initLoa