UPnP基本原理及应用

1 摘要

       随着计算机产业以及计算机网络技术的迅猛发展,越来越多嵌入式设备的出现和家庭网络的发展,实现各种设备的互联互通已经成为人们的迫切需求,而实现家庭网络互联互通的关键是家庭网络的中间件技术。业界各大厂商都提出了自己的解决方案,其中以微软提出的UPnP最具有发展前途,也获得了最广泛的支持,目前UPnP基本是家庭网络设备必须支持的特性之一。

       UPnP是通用即插即用(Universal Plug and Play)的缩写,主要用于设备的智能互联互通,使用UPnP协议不需要设备驱动程序,它可以运行在目前几乎所有的操作系统平台上,使得在办公室、家庭和其他公共场所方便地构建设备互联互通成为可能。

       本文介绍了UPnP所定义的基本协议(如SSDP、GENA、SOAP等),重点分析了UPnP实现的基本工作流程,并通过抓包工具捕获数据包,对各种流程传递的协议报文进行详尽分析,最后结合NAT技术,重点叙述UPnP在NAT技术中的应用。

2 UPnP的结构规范

       UPnP最大的愿景是希望任何设备一旦连接上网络,所有在网络上的设备马上就能知道有新设备加入,这些设备彼此之间能互相通信,更能直接使用或者控制它,一切都不需要人工设置,完全的即插即用。

2.1 UPnP的基本组件

       服务、设备和控制点是UPnP网络的基本组件,它们之间的关系图如图1所示:
图1  UPnP组件图

  • 设备(Device)

UPnP网络中定义的设备具有很广泛的含义,各种各样的家电、电脑外设、智能设备、无线设备、个人电脑等等都可以称之为设备。一台UPnP设备可以是多个服务的载体或多个子设备的嵌套。

  • 服务(Service)

在UPnP网络中,最小的控制单元就是服务。服务描述的是指设备在不同情况下的动作和设备的状态。例如,时钟服务可以表述为时间变化值、当前的时间值以及设置时间和读取时间两个活动,通过这些动作,就可以控制服务。

  • 控制点(Control Point)

在UPnP网络中,控制点指的是可以发现并控制其他设备的控制设备。在UPnP网络中,设备可以和控制点合并,为同一台设备,同时具有设备的功能和控制点的功能,即可以作为设备提供服务,也可以作为控制点发现和控制其他设备。

2.2 UPnP的部分术语

  • UUID

UUID含义是通用唯一识别码(Universally Unique Identifier),其目的是让分布式系统中的所有元素都有唯一的标识,其格式为xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx(8-4-4-16),分别表示当前的日期、时间、始终序列、全局唯一的IEEE机器标识,如果有网卡,则从网络的MAC地址获取,没有网卡则以其他方式获得。

  • UDN

单一设备名字(Unique Device Name),基于UUID,表示一个设备,在不同的时间,对于同一台设备此值应该是唯一的。

  • URI

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

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

  • URN

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

2.3 UPnP协议栈

UPnP定义了设备之间、设备和控制点、控制点之间通信的协议。完整的UPnP有设备寻址、设备发现、设备描述、设备控制、事件通知和基于Html的描述等几部分构成。UPnP设备协议栈如图2所示:
  图2 UPnP协议栈
       UPnP协议结构最底层的TCP/IP协议是UPnP协议结构的基础。IP层用于数据的发送与接收。对于需要可靠传送的信息,使用TCP进行传送,反之则使用UDP。UPnP对网络的底层没有要求,可以是以太网、WIFI、IEEE1394等等,只需支持IP协议即可。
       构建在TCP/IP协议之上的是HTTP协议及其变种,这一部分是UPnP的核心,所有UPnP消息都被封装在HTTP协议及其变种中。HTTP协议的变种是HTTPU和HTTPMU,这些协议的格式沿袭了HTTP协议,只不过与HTTP不同的是他们通过UDP而非TCP来承载的,并且可用于组播进行通信。

2.3.1 SSDP协议

简单服务发现协议(Simple Service Discovery Protocol:SSDP),是内建在HTTPU/HTTPMU里,定义如何让网络上有的服务被发现的协议。具体包括控制点如何发现网络上有哪些服务,以及这些服务的资讯,还有控制点本身宣告他提供哪些服务。该协议运用在UPnP工作流程的设备发现部分。

2.3.2 SOAP协议

简单对象访问协议(Simple Object Access Protocol:SOAP)定义如何使用XML与HTTP来执行远程过程调用(Remote Procedure Call)。包括控制点如何发送命令消息给设备,设备收到命令消息后如何发送响应消息给控制点。该协议运用在UPnP工作流程的设备控制部分。

2.3.3 GENA协议

通用事件通知架构(Generic Event Notification Architecture:GENA)定义在控制点想要监听设备的某个服务状态变量的状况时,控制点如何传送订阅信息并如何接收这些信息,该协议运用在UPnP工作流程的事件订阅部分。

3 UPnP实现的工作流程

图3是UPnP的运行流程,我们先大概介绍下
 图3 UPnP的运行流程

1、 首先控制点和设备都先获取IP地址后才能进行下一步的工作;
2、 控制点首先要寻找整个网络上的UPnP设备,同时网络上的设备也要宣告自身的存在;
3、 控制点要取得设备的描述,包括这些设备提供什么样的服务;
4、 控制点发出动作信息给设备;
5、 控制点监听设备的状态,当状态改变时作出相应的处理动作;

3.1 寻址(Addressing)

UPnP网络的基础是TCP/IP,这就决定了每一个UPnP组件必须有IP地址。一台UPnP设备寻址的一般过程是:首先向DHCP服务器发送DHCP Discover的消息,如果在指定的时间内,设备没有收到DHCP Offer回应消息,设备必须使用AUTO-IP完成IP地址的获取。当然也可以使用静态配置的IP地址。

3.2 发现(Discovery)

连接到网络上的设备确定了IP地址之后,就会进入发现操作阶段。设备发现是UPnP实现的第一步。设备发现是由简单发现协议SSDP来完成的。当一台设备加入到网络中,发现过程允许设备向网络上的控制节点告知它提供的服务,当一个控制点加入到网络中,设备发现过程允许控制点寻找网络上感兴趣的设备。在这两种情况下,基本的交换信息就是发现消息。发现消息包括设备的一些特定信息或者某项服务的信息,例如它的类型、标志符、等等。图4是发现流程的框架图:
  图4 发现过程框架图

SSDP发现请求用来寻找希望得到的设备及其服务。它使用SEARCH消息,用URI ssdp:discover标识。SEARCH消息必须包括一个ST(搜索类型)头,还可能含有消息体。ST头用来指明希望发现的设备及服务类型。目前只指定了在多播UDP中使用该请求,以后可能扩展到TCP。
只有那些与ST匹配的服务才可能通过SSDP端口给出响应,响应应该在AL头中表示出服务的地址,同时,响应中还要包括缓存控制信息:有效期。没有缓存控制信息的响应将被视作无效响应。本例没有设备的响应消息。以下是LIBRE控制点发出的发现设备请求消息:

M-SEARCH * HTTP/1.1
MX: 10
ST: urn:schemas-upnp-org:device:DDMSServer:1
HOST: 239.255.255.250:1800
MAN: ssdp:discover

从ST头可以知道,TV控制点搜索的设备是DDMSServer,设备号为1。其中HOST由互联网编号分配组织(IANA)为SSDP保留的多播信道和端口。必须是239.255.255.250:1800。MAN是强制扩展声明标头,一个含有强制扩展声明的HTTP请求被称作强制请求,在这个消息中使用强制扩展的用意在于确定接受方是否理解和支持ssdp:discover,接受方如果支持ssdp:discover,将会对扩展声明进行解析,否则返回出错信息。
SSDP存在宣告可以让SSDP客户知道设备及服务的存在、更新缓存中的过期信息、服务的位置改变或即将无效。SSDP存在宣告使用NOTIFY消息,NOTIFY消息包括位置和/或AL头部(指示设备及服务的地址)、NT头(指示设备及服务类型)、USN(唯一服务名称,可以和其它同类型服务相区别)以及Cache-Control或者Expiration头部(缓存控制信息)。对方收到后根据NOTIFY的NT判定是否是自己感兴趣的设备及服务。如果是,若缓存中未见此USN,则增加记录,否则更新记录。对此消息不需要给出响应。
类似如下格式数据:
TV设备发送的宣告消息
从NT头知道,TV设备是根设备,由NTS子类型知道,该设备目前可用,且由USN指出了TV设备的唯一设备名称UUID。

3.3 描述(Description)

UPnP的第二步是设备描述。在控制点发现一台设备后,控制点对该设备可能仅仅知道设备或者服务的UPnP类型,设备的UUID和设备描述的URL地址,还需要知道更多的信息。控制点可以从发现消息中得到设备描述的URL,通过URL取回设备描述的信息。设备描述的一般过程图如图5所示:
图5 设备描述以及服务描述

一般情况而言,在描述部分,控制点会得到两类描述,设备描述和服务描述,本例只获得了设备描述。因为TV设备只定义了一个服务,其变量为power、channel、volume。这三个变量直接是通过在代码里定义,然后进行操作的。
- 设备描述

UPnP对某一设备的描述以XML形式来表示,设备描述包括制造商信息、模块名称和编号、序列号等等。对于一个物理设备可以包含多个逻辑设备,多个逻辑设备既可以是一个根设备其中嵌入多个设备,也可以是多个根设备的方式存在。设备描述由设备制造商提供,采用XML描述,遵循UPnP框架协议。
控制点发送的GET请求消息
控制点是通过发送HTTP GET消息来请求获得设备描述的。GET指出了设备描述的路径,此处为设备描述URL(发现消息中的LOCATION标头);HOST指出了设备描述URL的域名或IP地址及可选端口部分。

  • 服务描述

服务的描述包含一系列内容,具体有服务运行时刻的状态,运行时间等等。服务描述也由设备制造商提供,采用XML描述,遵循UPnP框架协议
设备返回的设备描述消息
空白处前面的数据为HTTP消息头,描述了XML描述文件的一些基本信息,空白处下面的数据就为XML文件的具体内容

3.4 控制(Control)

在接收设备和服务描述之后,控制点可以向这些服务发出动作,同时控制点也可以轮询服务的当前状态。控制点将动作发送到设备服务,在动作完成或者失败后,服务返回相应的结果或者错误信息。其基本过程如图6所示:
  图6   控制过程示意图
为了控制一台设备,控制点向设备服务发出一动作,这一般是由控制点向服务的控制URL地址发送一个适当的控制消息。而服务则会对此动作出响应,返回相关的结果或错误。

3.5 事件(Even ting)

       如上文的描述部分所述,一个即插即用服务描述包括服务响应的动作列表和运行时描述服务状态的变量列表。如果一个或多个状态被事件触发,服务将会在这些状态发生变化时发布更新,控制点可以订阅以获得此信息。在事件机制中,发布者指事件的来源(通常为设备服务),订阅者指事件目的地(通常为控制点)。
        要订阅事件,订阅者可发送一条请求订阅消息。它将以这个订阅到持续时间作为响应。要保持订阅,订阅者必须在订阅过期之前进行续订。当订阅者不再需要发布者发送的事件时,订阅者应当取消其订阅。
       发布者通过发送事件消息提醒订阅者状态改变。在订阅者第一次订阅时,需要发送一个专门的初始化事件消息。该事件消息包含所有事件的名称和值,并且允许订阅者初始化其服务状态。为了支持多个控制点,在动作生效后所有订阅者均会收到通知。由此,将向所有订阅者发送全部事件消息。事件消息使用HTTP协议传送,事件详细定义在通用事件通知结构(GENA)协议中。

订阅请求的消息分析

对于设备中的每项服务,描述消息均包含一个事件触发URL(设备描述中服务元素的eventSubURL子元素)和UPnP服务标识符(设备描述中服务元素的serviceId子元素)。为订阅特定服务的事件,订阅消息将被发送到该服务的事件触发URL。(注意,事件触发URL可能相对于基本URL。)消息中含该服务的标识符以及事件消息交付URL。订阅消息还可能包含所要求的订阅持续时间。
订阅消息
由上图可知,本订阅消息订阅的是TV的control服务,CALLBACK指出了回送的路径,即TV控制点的IP和端口,NT指出了TV控制点想接受的事件消息,HOST指出了事件触发URL(设备描述中服务元素的eventSubURL子元素)的域名或IP地址和可选端口组件。TIMEOUT指出了直到订阅期满所要求的持续时间。
订阅的响应消息

由上图知,响应消息返回了一个用于本次订阅的订阅号SID,此SID在订阅期间必须是唯一的。DATE指出了响应生成的具体时间。

续订请求的消息分析

为续订特定服务的事件,续订消息将被发往该服务的事件触发URL。然而,与最初的订阅消息不同,续订消息既不包含服务标识符也不包含事件消息交付URL,而是包含由发布者(设备)分配的订阅标识符,为续订提供明确的参考。与订阅消息相同,续订消息还可能包含所要求的订阅持续时间。
续订请求数据包
由上图知,TV控制点直接通过SID完成对tvcontrol的续订任务。

NOTIFY事件通知消息分析

当设备的服务状态变量有变更时,设备会发布其状态变量变更的事件消息。对于控制点而言,在完成订阅或者续订了某项服务之后,它就会收到关于此服务的状态变量变更的事件消息。
以下是设备发送的关于tvcontrol的事件通知消息。
设备返回的tvcontrol服务的事件通知信息

在空白处上方是事件消息的命令行和标头。标头里的SEQ是事件编号,对于事件消息均标有事件编号,为便于进行错误检查,发布者必须保持每个订阅有一个单独的事件编号。当发布者发送初始化事件消息时,订阅事件编号被初始化为0(图 22所示的便是这种情况)。对于以后的每条事件消息,发布者会增加订阅事件编号,包括事件消息更新的编号。
空白处下方是该事件消息的消息体部分,以XML文档形式存在。在消息体内,指出了关于tvcontrol服务的所有状态变量(Power、Channel、Volume)及其当前值。

3.6 展示(Presentation)

在控制点发现设备和取得设备描述之后,展示也就开始了。如果设备拥有进行展示的URL,那么控制点就可以通过此URL取得一个页面,在浏览器中加载该页面,并根据页面功能,支持用户控制设备或浏览设备状态。每一项完成的程度取决于展示页面和设备的具体功能。
设备展示包含在设备描述的Presentation URL字段。设备展示可以完全由设备制造商提供,它采用HTML页的形式,使用HTTP进行发布。图7是展示的流程示意图:
     图7 展示示意图

动作调用的消息分析

  • SOAP动作调用
    简单对象访问协议(SOAP)定义使用XML和HTTP的远程过程调用。UPnP使用SOAP来向设备提供控制消息,并将结果或错误返回控制点。
    为了向设备的服务发出一个动作,控制点必须采用以下格式的POST方法发送一个请求。以下是TV控制点向TV设备发送的SOAP控制消息(以PowerOn为例):
    请求数据包和响应数据包
    前一部分是控制点发送的控制请求消息,采用POST方法,消息体为XML文件形式。在标头部分,HOST指出了控制此服务的域名或IP地址、以及URL可选端口组件(设备描述服务元素的controlURL子元素);SOAPACTION 是SOAP协议规定使用的标头,由调用的服务类型、散列符号和动作名称组成,均用双引号括起来,PowerOn为要发送的动作名称。在消息体部分,Envelope的“http://schemas.xmlsoap.org/soap/envelope”用来表示SOAP使用了HTTP扩展框架;Body指出了具体的控制动作(PowerOn)。
    后一部分是TV设备回送的响应消息,同样消息体以XML文件形式回复,回复消息表明了Power在动作执行后的当前值。在标头部分,DATE指出了响应生成的具体时间;在消息体的BODY部分,设备返回了被操作的服务状态变量(Power)在执行动作(PowerOn)后的当前值。

  • 事件通知的消息分析
    在控制点发送的动作消息,设备执行了之后,除了发送相应的响应消息,设备还会采用GENA协议发送一个事件通知消息给控制点,该消息会经由miniserver模块处理,然后由回调函数TvCtrlPointCallbackEventHandler()更新相应的状态变量表。
    动作执行后的通知消息数据包
    在数据包的消息体部分,返回了Power服务变量的当前值为1,即PowerOn的状态。

查询变量的消息分析

除了向设备的服务发出动作,控制点还可以对服务进行轮询,以通过发送查询消息获得状态变量值。查询消息只能查询一个状态变量,必须发送多个查询消息以查询多个状态变量。 此查询消息与该服务的事件(如果有)相分离。以下是TV例子所发送的查询消息和响应消息:
查询数据包
与前面的动作调用一样,前一部分是发送的查询请求消息,在标头部分,SOAPACTION中的QueryStateVariable表明是查询信息,这与动作调用区分开来;在消息体的BODY部分,指明了查询的服务状态变量(Power)及其所在的服务(control)。
后一部分是TV设备返回的响应消息,在消息体的BODY部分,返回了服务状态变量Power的当前值为1。

结论

        作为家庭网络的核心技术之一,UPnP充分重用互联网技术标准,提供服务的跨平台自动发现和远程控制。基于UPnP技术设计应用程序将非常简单,目前许多国家在制订家庭网络体系结构时都采用了该项技术,因此UPnP有良好的应用前景,有必要积极研究开发基于UPnP的设备和应用。
        论文系统地研究了UPnP及其相关协议,并结合TV控制点和设备的模拟实现,从规范描述和设备开发两个方面深入研究UPnP的实现技术。论文最后对捕获的数据包进行了详尽分析,为开发过程中的相关信息查询提供了有力参考,且为UPnP设备开发提供了事例借鉴。
        当然,UPnP技术的普及任重道远,从技术层面来讲,尚有许多工作需要做。例如,需要对更多的信息设备制定UPnP标准规范;需根据规范描述开发更多的UPnP设备产品;还有必要进一步研究UPnP技术与OSGI、Jini等技术之间的联系,以实现真正的家庭联网。

参考文献

[1] UPnP Forum,About UPnP[EB].http://www.UPnP.org
[2] W3C. Extensible Markup Language (XML)[EB]. http://www.w3.org/XML/, 2010/03/14。
[3] 肖继民. 基于UPnP 的家庭网络技术及实现研究[D]. 南京:南京邮电大学[硕士学位论文],2007.3。
[4] 王政军. 基于Intel UPnP SDK的UPnP协议编程[EB]. http://www.cqvip.com/qk/92317A/200507/18013100.html, 2007-3-18。
[5] 沈彬斌.UPnP中间件技术在数字家庭网络中的应用研究[D].成都:电子科技大学[硕士
学位论文],2006.02。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章