第一章 编译PlatinumKit-1-0-5-13_0ab854
官网：www.plutinosoft.com/platinum
下载SDK：sourceforge.net/projects/platinum/
1，配置NDK变量
环境名必须是叫ANDROID_NDK_ROOT .
- senrsl@senrsl-ubuntu:~$ echo $ANDROID_NDK_ROOT
- /home/senrsl/android/android-ndk-r10b
2，ndk目录下建个TAG文件
3，进入Platinum目录编译
- senrsl@senrsl-ubuntu:~$ cat ~/android/android-ndk-r10b/out/config.mk
- HOST_TAG:=linux-x86
senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum$ scons target=arm-android-linux build_config=Release
此时出现错误1.
再次编译，出现scons: done building targets.编译成功
验证编译结果
4，编译so库
- senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum$ ll Build/Targets/arm-android-linux/Release/
- 总用量 11116
- drwxrwxr-x 3 senrsl senrsl 4096 8月 18 19:03 ./
- drwxrwxr-x 4 senrsl senrsl 4096 8月 18 19:02 ../
- -rwxrwxr-x 1 senrsl senrsl 1063620 8月 18 19:03 FileMediaServerTest*
- -rwxrwxr-x 1 senrsl senrsl 764332 8月 18 19:03 FrameStreamer*
- -rwxrwxr-x 1 senrsl senrsl 754300 8月 18 19:03 HttpTest*
- -rw-rw-r-- 1 senrsl senrsl 141560 8月 18 19:03 libaxTLS.a
- -rw-rw-r-- 1 senrsl senrsl 1413222 8月 18 19:03 libNeptune.a
- -rw-rw-r-- 1 senrsl senrsl 1034980 8月 18 19:03 libPlatinum.a
- -rw-rw-r-- 1 senrsl senrsl 75590 8月 18 19:03 libPltMediaConnect.a
- -rw-rw-r-- 1 senrsl senrsl 180220 8月 18 19:03 libPltMediaRenderer.a
- -rw-rw-r-- 1 senrsl senrsl 332896 8月 18 19:03 libPltMediaServer.a
- -rw-rw-r-- 1 senrsl senrsl 101612 8月 18 19:03 libZlib.a
- -rwxrwxr-x 1 senrsl senrsl 948948 8月 18 19:03 LightSampleTest*
- -rwxrwxr-x 1 senrsl senrsl 1073032 8月 18 19:03 MediaConnect*
- -rwxrwxr-x 1 senrsl senrsl 1126568 8月 18 19:03 MediaCrawler*
- -rwxrwxr-x 1 senrsl senrsl 989148 8月 18 19:03 MediaRendererTest*
- -rwxrwxr-x 1 senrsl senrsl 1186160 8月 18 19:03 MicroMediaController*
- drwxrwxr-x 8 senrsl senrsl 4096 8月 18 19:03 Source/
- -rwxrwxr-x 1 senrsl senrsl 42192 8月 18 19:03 TextToHeader*
- -rwxrwxr-x 1 senrsl senrsl 108604 8月 18 19:03 TimeTest*
检查一下是否生成成功
- senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum$ cd Source/Platform/Android/module/platinum/jni/
- #检查一下，我看这个版本没什么要改的
- senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum/Source/Platform/Android/module/platinum/jni$ vi Android.mk
- senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum/Source/Platform/Android/module/platinum/jni$ $ANDROID_NDK_ROOT/ndk-build NDK_DEBUG=0
- [armeabi] Compile++ thumb: platinum-jni <= platinum-jni.cpp
- [armeabi] StaticLibrary : libstdc++.a
- [armeabi] SharedLibrary : libplatinum-jni.so
- [armeabi] Install : libplatinum-jni.so => libs/armeabi/libplatinum-jni.so
- [armeabi-v7a] Compile++ thumb: platinum-jni <= platinum-jni.cpp
- [armeabi-v7a] StaticLibrary : libstdc++.a
- [armeabi-v7a] SharedLibrary : libplatinum-jni.so
- [armeabi-v7a] Install : libplatinum-jni.so => libs/armeabi-v7a/libplatinum-jni.so
5,导入demo,测试生成的so
- senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum/Source/Platform/Android/module/platinum/jni$ tree ../libs/
- ../libs/
- ├── armeabi
- │ └── libplatinum-jni.so
- └── armeabi-v7a
- └── libplatinum-jni.so
- 2 directories, 2 files
导入这俩，发现一个是lib,一个是project,启动后日志
- senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum/Source/Platform/Android$ ll
- 总用量 16
- drwxrwxr-x 4 senrsl senrsl 4096 4月 2 2014 ./
- drwxrwxr-x 3 senrsl senrsl 4096 4月 2 2014 ../
- drwxrwxr-x 3 senrsl senrsl 4096 4月 2 2014 module/
- drwxrwxr-x 3 senrsl senrsl 4096 4月 2 2014 samples/
有什么用。。。。
- 08-18 19:25:36.608: V/Settings(27789): invalidate [system]: current 4 != cached 0
- 08-18 19:25:36.608: D/Neptune(27789): [Java_com_plutinosoft_platinum_UPnP__1start] INFO: start
- 08-18 19:25:36.608: D/Neptune(27789): [Start] INFO: Starting UPnP...
- 08-18 19:25:36.619: D/Neptune(27789): [Bind] FINE: setting SO_REUSEADDR option on socket
- 08-18 19:25:36.619: D/Neptune(27789): [LeaveGroup] FINE: leaving multicast addr 172.16.10.106 group 239.255.255.250
- 08-18 19:25:36.619: D/Neptune(27789): [LeaveGroup] FINE: setsockopt error -22099
- 08-18 19:25:36.619: D/Neptune(27789): [JoinGroup] FINE: joining multicast addr 172.16.10.106 group 239.255.255.250
- 08-18 19:25:36.619: D/Neptune(27789): [NPT_PosixThread] FINE: NPT_PosixThread::NPT_PosixThread
- 08-18 19:25:36.619: D/com.plutinosoft.platinum.sample.PlatinumUPnPActivity(27789): upnp.Start returned: 0
错误
错误1,arm-linux-androideabi-g++: not found
编译PlatinumKit-1-0-5-13_0ab854/Platinum
命令
出现错误。
- senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum$ scons target=arm-android-linux build_config=Release
修改文件
原内容
- senrsl@senrsl-ubuntu:~/test/PlatinumKit-1-0-5-13_0ab854/Platinum$ vi Build/Targets/arm-android-linux/Config.scons
- ANDROID_CROSS_PREFIX = 'arm-linux-androideabi'
- ANDROID_CROSS_PREFIX = '/home/senrsl/android/android-ndk-r10b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi'
第二章 DLNA介绍
2015年08月18日20:50:27
搞了半天第一章不知道干嘛的，然后去复制点理论来瞧瞧↓
一、DNLA的建立
DLNA 成立于2003 年6 月24 日, 其前身是DHWG （Digital Home Working Group 数字家庭工作组），由Sony、Intel、Microsoft等发起成立、旨在解决个人PC ，消费电器，移动设备在内的无线网络和有线网 络的互联互通，使得数字媒体和内容服务的无限制的共享和增长成为可能。DLNA的口号是Enjoy your music, photos and videos, anywhere anytime。该组织的官方网站是www.dlna.org . 页面主色调green,black,white,silver和gray，后面要讲到的UPnP的主业也是同样的调调，这两个关系挺大的，后 面讲。
二、DLNA的成员
这个组织将加入者分为两个层次，最高层次为promoter, 其次为contributor。promoter制定标准和协议，contributor可以分享这个组织的资源，也可以提交标准，参与讨论。现在绝大多 数的电子制造商都加入了该组织，至少是contributor，而且年费还很贵。成员名单可以从http://www.dlna.org /about_us/roster/中可以找到。
下图是2008年DLNA的promoter：
图呢
下图是2011年的promoter：
图呢呢
从上面两个图我们可以看见，DLNA的骨干成员包括以Intel为首的芯片制造商；以HP为首的PC制造商，以 Sony，Panasonic，Sharp，Samsung，LG 为首的家电、消费电子制造商；以 CISCO，HUWEI，MOTOROLA，ERICSSON为首的电信设备/移动终端/标准商；一家独大的Microsoft软件/操作系 统商等等。
值得注意的有几点：
1.DLNA这个东西基本Intel，Microsoft两个领域巨头在推，一个搞芯片，一个搞系统。AMD没出现在2011的promoter名单 中；Google来年会不会掺一脚不好说。还有QUALCOMM也参加进来了，这几年的智能手机芯片处理器他家的也比较多，而且他家还有很多 专利可以吃。
2.2011就剩HP一个大PC商了，其他大PC商如Acer,Asus都还不是promoter，他们肯定要抢着加入的。lenovo不仅从 promotor名单中消失了，自然也不会是contributor了，和AMD一样。最开始时lenovo是很积极的，在DHWG的时候也 是骨干成员，回来中国搞了一个"IGRS闪联"，退出的原因不知道和这个有没有关系。IGRS在很大程度上和DLNA是比较类似的，框架协议 和UPnP也是比较像的。
3.Awox和Cablelabs都是做互联多媒体设备的。Broadcom主要是做移动消费电子，有硬件solution，也有产芯片。
4.ACCESS（爱可视）是做软件的。现在软件的需求很大，给第三方提供软件solution是一块很大的蛋糕。 cyberlink和arcsoft也在做这方面，已经有些成熟的软件solution了，像EMC，NeuSoft也有在做。
5.运营商开始加入了，像at&t美国电报电话公司，at&t也挺厉害的，到处搞签约机，像是跟PSP VITA也签了。以后中国移动联通不知道会不会也跑来参加(有点难...)。
6.dts和dolby都是做音视频标准的，他们基本是跑来收钱的，你机器上到他们的专利你就得付钱，跟以后肯定其他人也会跑来收钱。
三、DLNA标准的制定
该组织旨在建立一个基于开放的工业标准的互操作平台，并将确立技术设计规则，供企业开发数字家庭有关的产品。其工作目标是根据 开放工业标准制定媒体格式，传输和协议互操作性的指南和规范，和其他工业标准化组织进行联络，提供互操作性测试，并进行数字家庭市场计划的制 定和实施。
DLNA并不是创造技术，而是形成一种解决的方案，一种大家可以遵守的规范。所以DLNA选择的各种技术和协议都是目前所应用很广泛的技术和协议。所以 很多家都要参加，希望DLNA采纳自己的协议和标准，以后自己好办事，可以的话顺便吃点专利费。大方向上肯定打不过Intel和 Microsoft的，只能跟着他们走，可以提起其他方面的协议和标准。DLNA的标准写在DLNA GUIDELINES里面，就是大家开会一起写出来的，再开会不停修改的一个standard，一个specification。参加DLNA的商家必须 按这个标准走。里面内容不太清楚，我现在没有这个GUIDELINES，这个必须是DLNA会员才能拿到，我在的公司已经不是会员了，拿不到 了，加会员要10000刀。改天看能不能找Cyberlink拿份coppy。
下面先大概看看DLNA的一些architecture，model和sdandard，都是从网上抄过来的，其他的等拿到 Guidelines再补充。
四、DLNA的设备
在讲DLNA的架构之前先讲一下DLNA规定的设备分类，这些设备就是DLNA标准执行的物理和逻辑对象。
这是一个DLNA 设备的类图。
1.Home NetWork Device(HND)。这类设备指家庭设备，具有比较大的尺寸及较全面的功能，主要与移动设备区别开来，下属5类设备：
(1)Digital Media Server(DMS)。数字媒体服务器，提供媒体获取、记录、存储和输出功能。同时，内容保护功能是对DMS的强制要求。
DMS总是包含DMP的功能，并且肯能包含其他智能功能，包括设备/用户服务的管理；丰富的用户界面；媒体管理/收集和分发功 能。DMS的例子有PC、数字机顶盒（附带联网，存储功能）和摄像机等等。
(2)DMP。数字媒体播放器。能从DMS/M-DMS上查找并获取媒体内容并播放和渲染显示。比如智能电视、家庭影院等
(3)DMC。数字媒体控制器，查找DMS的内容并建立DMS与DMR之间的连接并控制媒体的播放。如遥控器。
(4)DMR。数字媒体渲染设备。通过其他设备配置后，可以播放从DMS上的内容。与DMP的区别在于DMR只有接受媒体和播 放功能，而没查找有浏览媒体的功能。比如显示器、音箱等。
(5)DMPr。数字媒体打印机，提供打印服务。网络打印机，一体化打印机就属于DMPr。
2.Mobile Handheld Devices(MHD)手持设备。相比家庭设备，手持设备的功能相对简化一些，支持的媒体格式也会不同。
(1)M-DMS。与DMS类似，如移动电话，随身音乐播放器等。
(2)M-DMP。与DMP类似。比如智能移动电视。
(3)M-DMD。移动多媒体下载设备。如随身音乐播放器，车载音乐播放器和智能电子相框等
(4)M-DMU。移动多媒体下载设备。如摄像设备和手机等。
(5)M-DMC。与DMC类似。P如DA，智能遥控器。 手持设备没有定义M-DMR，因为手持设备会讲究便利性，会附加查找控制功能，要不然就只是普通的移动电视或收音机了。
3.Networked Infrastructure Devices (NID) 联网支持设备。
(1)Mobile Network Connectivity Function (M-NCF)。移动网络连接功能设备。提供各种设备接入移动网络的物理介质。 DLNA的希望是全部实现无线化。
(2)Interoperability Unit (MIU)媒体交互设备。提供媒体格式的转换以支持各种设备需要。
设想一下这样一个scenario：你下了班回到家，掏出手机拨到家庭模式，然后就在手机上遥控打开了等离子 电视和PC，然后把订阅的新闻通过PC下载完成后打到等离子电视上播放。这时手机就是一个DMC/M-DMC，等离子电视是一个DMR，PC 就是DMS。然后你手机上收到一张朋友从巴西传来的照片，你看完之后把它同步到PC上存储起来，这样手机现在的身份是M-DMU，然后你把这 张图片放到电子相框里面。这个电子相框就是一个M-DMD，相框也有play的能力，所以他又是一个M-DMP。所以说这些设备的功能角色都 是不定的，界限也不是那么严格。在DLNA Guidelines v1.0的时候还没有智能手机，后来在v1.5加入了。这个设备分类只是定义了功能，而且功能也会变的。以后还会出其它新设备，像 pad,tab,touch各种各样，到时候标准也会变的。
五、DLNA的架构
DLNA架构是个互联系统，因此在逻辑上它也类似OSI（Open System Interconnection，开放系统互连）七层网络模型。
DLNA架构分为如下图7个层次：
没图
DLNA ARCHITECTURE
(1) NetWorking Connectivity 网络互联方式:包括物理连接的标准，有有线的，比如符合IEEE802.3标准的Ethernet，；有无线
的 ，比如符合IEEE802.11a/g标准的WiFi，能做到54Mbps，蓝牙(802.15)等,技术都很成熟。现在 OFDM和MIMO(802.11n)已经能做到300Mbps了，早就超过比较普及的100Mbps的Ethernet了，只不过产品还没 有普及，以后肯定会用到。
(2) NetWorking Stack 网络协议栈：DLNA的互联传输基本上是在IPV4协议簇的基础上的。用TCP或者UDP来传都可以。这一层相当于OSI网络层。
(3)Device Discovery&Control 设备发现和控制。
这个层次是比较essential的，是DLNA的基础协议框架。DLNA用UPnP协议来实现设备的发现和控制。下面重点看一下UPnP。
这一部分可以看一下http://upnp.org/sdcps-and-certification/standards/device- architecture-documents/里的文档。UPnP的工作过程 一文也做了详细说明。下面概括总结性地说一说。
UPnP，英文是Universal Plug and play，翻译过来就是通用即插即用。UPnP最开始Apple和Microsoft在搞，后来Apple不做了，Microsoft还在继续 做，Intel也加进来做，Sony，Moto等等也有加入。UPnP有个网站http://www.upnp.org /，我们发现DLNA 的网页和UPnP的网页很像，颜色也差不多，就可以知道他们关系很好了。DNLA主要是在推UPnP。
微软官方网站对UPnP的解释：通用即插即用 (UPnP) 是一种用于 PC 机和智能设备（或仪器）的常见对等网络连接的体系结构，尤其是在家庭中。UPnP 以 Internet 标准和技术（例如 TCP/IP、HTTP 和 XML）为基础，使这样的设备彼此可自动连接和协同工作，从而使网络（尤其是家庭网络）对更多的人成为可能。
举个例子。我们在自己的PC（win7）里面打开网络服务的UPnP选项，然后再家庭网络中共享一个装着视频的文件夹，然后买一台SmartTV回来打 开就可以找到这台PC的共享文件夹，然后就直接在电视上选文件播放了。
UPnP的另外一个作用是给家庭网内的devices做自动的网络地址转换NAT(NAT,Network Address Translation)和端口映射(Port Mapping)，因为家庭网络里面没有那么多IP，所有的devices可能都要通过同一个ip出去。转换映射之后，家庭网络内外的devices就可 以通过internet自由地相互连接，而不受内网地址不可访问的阻碍。
UPnP Device Architecture 1.0中会说明设备是怎样通过UPnP来相互发现和控制，以及传递消息的。我们会专门用一章的篇幅来讲一下UPnP Device Architecture，可见下文中的扩展阅读I： UPnP的工作过程
(4)Media Management媒体管理。媒体管理包括媒体的识别、管理、分发和记录（保存），UPnP AV Architecture:1 and UPnP Printer Architecture:1这两个属于UPnP的文档会说明如何进行媒体管理。我将在 扩展阅读II：UPnP AV Architecture 一文中稍微详细介绍UPnP AV设备和CP之间的交互模型及媒体的控制。
UPnP AV Architecture 定义了UPnP AV设备间媒体传送以及和CP间的交互。UPnP AV也定义了两种UPnP AV设备：UPnP AV MediaServer（MS）和UPnP AV MediaRender（MR），以及他们具有的4种服务：
1)Content Directory Service(CDS)：能将可访问的媒体内容列出。
2)Connection Manager Service(CMS)：决定媒体内容可以通过何种方式由UPnP AV Media Server传送至UPnP AV MediaRender。
3)AVTransport Service：控制媒体内容，比如播放、停止、暂停、查找等。
4)Rendering Control Service：控制以何种方式播放内容，比如音量、静音、亮度等。
UPnP Printer Architecture:1 定义了打印设备和CP的交互模型，这将不再细说。
(5) Media Transport 媒体传输：这一层用HTTP(HyperText Transfer Protocol)超文本传输协议。就是平时我们上网用的媒体传输协议。HTTP用TCP可靠传输，也有混合UDP方式的HTTP。现在HTTP的最新版 本是HTTP1.1。可选协议是RTP。
exsample：我们输入一个网址，回车，给server发一个request，用TCP我们就可以等server给我们消息，说明server收到我 们的消息了，否则我们就重发；接着server给我们TCP包，我们收一个就给server回信说我们收到了，要是server收不到回信， 他就认为包丢掉了，会再传一个同样的包过来。不停地回信就是会比较慢。
那如果我们用UDP会怎样？就是说我们不给server回信说我们收到编号是x的包了，server也就不给我们重发丢掉的包了，这样我们就丢包了。
但是我们传stream的时候，比如视频流，不用存，看完就完了，这种时候就可以用UDP来传。加上局域网里面QoS本来就很高，丢包都是不太可能的。所 以UDP肯定会用。局域网多播的时候也用UDP，这个在后面讲。
媒体的传输方案如下：
1)从DMS/M-DMS至DMP/M-DMP，即使不立即播放。
2)从一个DMS到另一个DMS，这时接收方DMS播放接收媒体内容，表现为一个DMP；也可以不立即播放，可能只是存储或者 处理。
媒体传输 模式有三种：
1)流传输。当DMR/DMP需要实时渲染接收媒体，媒体具时序性。
2)交互传输。不包含时序的媒体，如图片传输。
3)后台传输。非实时的媒体传输，比如上传下载等。
(6)Media Formats媒体格式。格式Formats在这里等同于编码格式Codec，平时我们说的编码格式比如Mpeg-2，AVC，x264就是视频编码格 式；PCM，mp3(MPEG-2 Layer 3)，aac，flac就是音频编码格式。而avi，rmvb，mkv这些是媒体封装格式，包含视频音频可能还有字幕流。比如一个常见的后缀为mkv的文 件，它的视频Codec是x264，音频是aac，它的视音频编码属于Mpeg-4 Codec Family。
我们知道不同设备对编码格式的支持能力不同，Media Formats这一部分规定了设备应该具有的格式支持能力。下面的表是DLNA支持的所有编码格式：
DLNA-proved format
| Video | Audio | Images | |
| MPEG-1 MPEG-2 H.263 MPEG-4 Part 2 MPEG-4 Part 10 WMV9 VC-1 |
LPCM MPEG-1/2 L2 MPEG-1/2 L3 MPEG-4 AAC LC MPEG-4 AAC LTP MPEG-4 HE AAC MPEH-4 BSAC | AC-3 ATRAC3plus WMA WMA Professional AMR AMR-WB+ G.726 | JPEG PNG GIF TIFF
|
针对家庭设备和手持设备，DLNA有不同的格式规定
(7)Remote UI 远程用户接口。说白了就是遥控器。比如说有个TV，我们说不管是用遥控器还是直接在TV上按按钮，效果是一样的。不过两者按钮的排列布局是不一样的。好 了，现在到DLNA了，我想用手机当遥控器可不可以？当然可以，只要获得TV上按钮的功能，传到手机上来，模拟一个遥控器就好了。DLNA现 在想用浏览器的方式，TV给你一个XML，手机上就出现遥控器界面了，有点像webQQ，webOS那种，这样在手机上就不需要客户端 了，TV功能更新了，手机直接跟TV要新的XML，很方便。
-------------------------------------------------------------------------------------------------------------------------------
扩展阅读I： UPnP的工作过程
UPnP的工作过程分为6步：
（1）寻址(Addressing)。
地址是整个UPnP系统工作的基础条件，每个设备都应当是DHCP（Dynamic Host Configuration Protocol 动态主机配置协议）的客户。当设备首次与网络建立连接后，利用DHCP服务，使设备得到一个IP地址。这个IP地址可以是DHCP系统指定的，也可以是由 设备选择的。当局域网内没有提供DHCP服务时，UPnP设备将按照Auto-IP的协议，从169.254/169.16地址范围获取一个 局域网内唯一的IP地址。设备还可以使用friendly name，这就需要域名解析服务（DNS）来转换name和IP。这个过程用到的东西都是现存的，而且是很普及的，市面上买的路由器都会有。
（2）发现(Discovery)。
发现是 UPnP工作第一步。 当一个 设备被添加到网络后，UPnP的发现协议允许该设备向网络上的 Control Points(CPs)通知(advise)自己拥有的服务。同样，当一个CP被添加到网络后， UPnP发现协议允许该CP 搜索网络上可用的设 备 。 这两种情况下的组播消息一般是设备和服务的基本信息，如它的类型， 唯一标识符，当前状态参数等等。要注意设备信息和服务信息都是要 组播出去的。发现的过程可以用下面Figure 1-1来描述。
下面详细叙述UPnP发现设备用到的协议：SSDP(Simple Service Discovery Protocol，简单服务发现协议)，说明设备是怎样向网络通知或者撤销自己可以提供的服务；CP是如何搜索设备以及设备是如何回应搜索 的。
SSDP格式套用HTTP1.1的部分消息头字段，但是和HTTP不同，SSDP是采用UDP传输的，而且 SSDP没有Message Body，就是说SSDP只有信头而没有信件内容的。
SSDP第一个要填充的字段是star - line，说明这是个什么类型的消息。
比如填"NOTIFY * HTTP/1.1/r/n"，就说明这个SSDP消息是个通知消息，一般设备加入网络或者离开网络都要NOTIFY，更新自己的服务后也要NOTIFY一 下。别的设备看见这个消息的star - line就知道有设备状态变了，自己就打开这个消息看一下有没有需要更新的。如果填"NOTIFY * HTTP/1.1/r/n"，就要填LOCATION字段，填一个description URL，CP可以通过这个地址来取得设备的详细信息。
填"M-SEARCH * HTTP/1.1/r/n"就是要搜索了；respone别人的搜索就填"HTTP/1.1 200 OK/r/n"。
SSDP第二个要填充的字段是目的地址HOST。比如填上"HOST: 239.255.255.250:1900"，就是组播(multicast)搜索，这里239.255.255.250是组播地址，就是说这条消息会给 网络里面该组地址的设备发，1900是SSDP协议的端口号。如果HOST地址是特定地址，那这就是单播(unicast)。Respone 不填这个字段，他会在ST字段里面填respone address，就是发来搜索信息的设备的地址，Respone消息的话还会发送一个包含自己地址URL的字段，Respone的意思就是跟 Searcher说：我好像是你要找的人，我的电话是XXX，详细情况请CALL我。Respone也是UDP单播。
往后的字段就不细说了。通过字段的组合可以发送很多不同的信息。
（3）描述(Description)
前面我们说了CP想要一个device更详细的信息，就打给它的URL跟它要。返回来的东西一般是个XML（Extensible Markup Language，是种结构化的数据。和HTML比较像，有tag和data，具体不说了自己去查），描述分为两部分：一个是device description，是device的物理描述，就是说这个device是什么；还有一个是service descriptions，就是device的服务描述了，就是device能干些什么。这些device和device service的描述的格式也是有要求的，开发商也可以自定义，只要符合UPnP Forum的规范。
这里稍微解释一下设备描述和服务描述。
首先说设备，比如一个家庭影院，有显示屏，有功放音响，还有蓝光机。那么这个家庭影院home threatre，就是一个根设备(root device)，它下属有Screen，Amplifier,BDplayer这些从设备。home threatre的描述XML中会有一个device list,列出Screen，Amplifier,BDplayer这些设备的基本信息及这些设备描述的URL，以及设备的 presentationURL（这类似于web服务器，通过访问presentationURL，本地会加载一个网页，在这个网页上可以操 作设备及其它拥有的服务）；还会有一个sevice list,里面列出home threatre可调用的服务基本信息及服务描述URL。
再来是服务，通过访问服务描述URL，可以取得服务描述XML，里面会详细介绍服务的信息，包括干什么用的，属于哪个设备，有哪些action，需要哪些 参数，怎么调用等等。
（4）控制(Control)
拿到device description和service descriptions以后，那我们怎么去遥控这些设备呢？
在设备描述部分，device description还有关于如何控制device的描述，会给出一个Control URL，CP可以向这个URL发送不同的控制信息就可以控制device了，然后device也可以返回一个信息反馈。
这种CP和device之间沟通信息按照Simple Object Access Protocol (SOAP)的格式来写。SOAP通过HTTP来传，现在的版本是1.1，叫做SOAP 1.1 UPnP Profile。这个Profile把控制/反馈信息分成三种：UPnP Control Request，UPnP Control Response和UPnP Control Error Response，都比较好理解。SOAP协议是有信内容Body的，和SSDP不一样。消息Body里面就可以写想调用的动作了，叫做Action invocation，可能还要传参数，比如想播放一个视频，要把视频的URL传过去；device收到后要respone，表示能不能执行 调用，出错的话会返回一个错误代码。
（5）事件(Eventing)
在服务进行的整个时间内，只要变量值发生了变化或者模式的状态发生了改变，就产生了一个事件，该事件服务提 供者(某设备的某个服务)会把该事件向整个网络进行多播（multicast）。而且，CP也可以事先向事件服务器订阅事件信息，就像RSS 订阅一样，保证将该CP感兴趣的事件及时准确地单播传送过来（unicast）。
下面是一个Unicast eventing 的architecture图，CP是subscriber，服务器是publisher。
subscriber(通常是个CP)向publisher(通常是个service)发送订阅消息(subscribe)，更新订阅消息 (renewal)，退订消息(cancel)。publisher向subscriber推送订阅(event:SIDX)。
事件的订阅和推送这块用的通信协议是GENA(General Event Notification Architecture) ，通过HTTP/TCP/IP传送。GENA的格式就不细说了，详细请参阅UPnP-arch-DeviceArchitecture-v1.1。下面列 出订阅过程供参考：
1.订阅。subscriber发送订阅消息主要包含事件URL(evenURL)，服务ID号(service identifier),这两个可以在设备服务描述信息中找到，以及寄送地址(delivery URL)。还会包含一个订阅期限(duration)。
2.成功订阅。publisher收到订阅信息，如果同意订阅的话就会为每个新subscriber 生成一个唯一的 subscriber identifier并记录subscriber 的duration和delivery URL。还会记录一个顺序增长event key用来保证事件确实推送到subscriber那里。比如说有个新事件，key是6，然后把这个事件推送给某个subscriber那 里，subscriber那里记录的event key是4，现在收到的事件key是6，他就知道他没收到key为5的事件，这样他就向publisher索要漏收的事件，从而保证双方变量值或状态的一 致。
3.首次推送。订阅同意订阅之后还会向subscriber发送一组初始变量或状态值，进行首次同步。
4.续订。subscriber必须在订阅到期前发送renewal续订。
5.订阅到期。订阅到期后publisher会把subscriber的信息删除，subscriber又回到订阅前的状态。
6.退订。subscriber发送cancel信息将会取消订阅。subscriber因非正常退出网络的话，则不会退订直 到订阅到期。
7.订阅操作失败信息。当订阅、续订和退订不能被publisher接收或者出现错误时，publisher会发送一个错误代 码。
再简单说下多播（multicast，或者叫组播，本文中两者等同）和单播。even的组播采用 UDP/IP，和SSDP一样，就是端口号变成了7900。下图是几个协议的所处层的位置，可以清楚地看到它们之间的差别。首先关于IP多 播，要知道只存在UDP多播，没有TCP多播这回事。为什么呢？多播的重点是提高网络效率，将同一数据包发送给尽可能多的可能未知的计算机。 像这种对网内所有设备的频繁消息通知采用多播是为了减小网络负担，SSDP也是一样。
但是SSDP和multicast这种采用UDP方式的协议存在一个问题，就是可靠性不够。解决的办法就是多次通知，但是一般不会超过三次以免增加网络负 担，这样就得不偿失了。像SSDP的话会采用定期广播advertice的方式，使各种各样原因而没收到advertice的CP重新获得 advertice，又解决了UDP丢包的问题。
前面在寻址的时候用到的DHCP用的是UDP广播(broadcast)。当一个新的设备加入网络时，他想要分个IP，但又不知道DHCP服务器的IP地 址，所以他就在网内广播，用255.255.255.255地址来通知所有计算机。DHCP服务器收到请求后会为他申请并返回一个IP地址。
（6）表达(Presentation)
只要得到了设备的URL，就可以取得该设备表达的URL，取得该设备表达的HTML，然后可以将此HTML纳入CP的本地浏 览器上。这部分还包括与用户对话的界面，以及与用户进行会话的处理。因此设备表达可以理解成"遥控器"。这部分定义描述界面，规范界面以及传 输界面内容。远程界面是供CP用户使用的，CP用户通过远程界面完成设备描述的获取，控制设备，订阅收取设备事件等等。
好了， 到此，UPnP的工作过程的讲解就结束了。总结一下：
UPnP分为6个步骤：
先是Addressing，设备加入网络，通过DHCP或者Auto-IP获得IP；这部分在闪联IGRS中是没有定义的。
然后是Discovery，采用SSDP协议(UDP)，用multicast/unicast可以完成设备的上线和离线通知 和组播搜索设备，设备用unicast(单播,UDP)响应CP的搜索。
往下是Description，通过HTTP协议(TCP)取回来是一个XML文档，包含物理描述和服务描述；
再来是Control，采用SOAP协议(HTTP/TCP)，完成CP和devices之间的交互；
Eventing，采用GENA协议(HTTP/TCP)，完成设备事件消息的订阅和推送，为保证可靠性，故是TCP传输；事 件的推送还有multicast (UDP)。
最后是Presentation。UPnP并没有定义Presentation应该有哪些东西。一个HTML嘛，哪样写得好哪 样来！
扩展阅读II UPnP AV(Audio/Video) Architectur
1.概述
下面是讲解UPnP AV的会用到的一些对象术语。
Table1-1: Default Short Names for the AV Specifications
| AV Specification Name | Short Name |
| AVTransport | AVT |
| ConnectionManager | CM |
| ContentDirectory | CD |
| MediaRenderer | MR |
| MediaServer | MS |
| RenderingControl | RCS |
| ScheduledRecording | SRS |
在UPnP AV Architecture:1 (Document Version: 1.1) 文档最开始的是这样介绍的UPnP AV的：
本文档描述了整体的UPnP AV 架构 。该架构是 UPnP AV 设备和服务范例的基础架构。
该架构定义了 UPnP 控制端与 UPnP AV设备基本交互，并且与特定设备类型，媒体内容格式与传输协议无关。它支持如电视机，录像机和 CD / DVD 播放机 / 自动点唱机，机顶盒，音响系统， MP3 播放器，静止图像照相机，摄像机，电子相框，以及 PC 等各种设备，。该 AV 架 构允许设备支持不同格式的多媒体格式（如 MPEG2， MPEG4 和 JPEG 格式， MP3 ， Windows 媒体架构 （ WMA ），位图（ BMP ）， NTSC 制式， PAL 制式，ATSC 标准等）和多种类型的传输协议，如 IEC- 61883/IEEE-1394 ， HTTP GET ， RTP 协议， HTTP 的 PUT/邮政， TCP / IP 协议等）。以下各节描述了 AV 架构，以及如何各种 UPnP AV 设备和服务协同工作，使各种最终用户的情况。
"与特定设备类型，媒体内容格式与传输协议无关"的内在含意是 UPnP AV Architecture只是提供了某种机制、模型，并没有规定采用
何种技术来实现。技术的实现部分在 UPnP Device Architecture中有说明。
UPnP AV Architecture 定义了 UPnP AV 设备间媒体传送以及和 CP 间的交互。 UPnP AV 也定义了两种 UPnP AV 设备： UPnP AV MediaServer （ MS ）和 UPnP AV MediaRender （ MR ），以及他们具有的 4 种服务：
1)Content Directory Service(CDS) ：能将可访问的媒体内容列出。
2)Connection Manager Service(CMS) ：决定媒体内容可以通过何种方式由 UPnP AV Media Server 传送至 UPnP AV MediaRender 。
3)AVTransport Service ：控制媒体内容，比如播放、停止、暂停、查找等。
4)Rendering Control Service ：控制以何种方式播放内容，比如音量、静音、亮度等。
2.UPnP AV 设备的交互模型
在设备交互中， CP 是最重要的，因为 Action 通常是由 CP 发出的。 UPnP AV 架构 对 CP 的功能要求有 10条：发现 AV 设备，获得所需的内容列表，获得渲染器支持的协议 / 格式，比较 / 匹配协议 / 格式， 配置服务器 /渲染器，选择所需的内容，开始内容传输，调整渲染参数，重复：选择下一个内容，断开服务器和渲染器连接。
CP可以是MediaServer，也可以是MediaRenderer，也可能只是遥控器remote control。根据CP的角色，归纳出下面三种常见的AV设备交互模型：
(1)2-Box Pull Model
这种情况下CP是MediaRenderer，它可以是一个智能手机。CP主动向MediaServer索取媒体内容，获得内 容之后播放媒体，是拉(pull)的方式。
CP要做的是 获得媒体列表>选取所需内容>匹配协议 / 格式，MediaServer需要 选取所需内容>匹配协议 / 格式>开始传 输。
(2)2-Box Push Model
这种情况下CP是MediaServer，它可以是一个一体机。CP主动向MediaRenderer推送(push)媒体。
CP要做的是 本地选取所需内容>匹配协议 / 格式>传输;MediaRenderer需要仅仅需要 匹配协议 / 格式>接收媒体。
(3)3-box model
在 3-box model中，CP仅仅作为一个遥控器。也分为pull和push两种方式。
当pull方式时，CP向Renderer发送Server及Server上所需媒体内容的URL，让Renderer去取；
当push方式时，CP向Server发Renderer的URL，让Server去向Renderer推送媒体内容。
↑
好了，这篇文章的复制粘贴结束。
第三章 UPnP协议编程实践
继续复制
UPnP协议编程实践
本专题主要是介绍UPnP的工作原理和基本概念，包括SSDP、GENA和FXPP等基本协议，以及在 Linux下如何使用Intel提供的UPnP开发包实现UPnP控制点和设备。本文是这个专题的第一篇，主要介绍UPnP的工作原 理和基本概念。
UPnP是通用即插即用（Universal Plug and Play）的缩写，它主要用于实现设备的智能互联互通。使用UPnP协议不需要设备驱动程序，因此使用UPnP建立的网络是介质无关的，它可以运行在几乎 所有的操作系统平台之上，可以使用C，C++，JAVA和VB等开发语言，使得在办公室、家庭和其他公共场所方便地构建设备相互联通 的网络环境。
本专题主要是介绍UPnP的工作原理和基本概念，包括SSDP、GENA和FXPP等基本协议，以及在Linux下如何使用 Intel提供的UPnP开发包实现UPnP控制点和设备。本文是这个专题的第一篇，主要介绍UPnP的工作原理和基本概念。本专题 其后的部分会详细介绍SSDP、GENA的概念，及其在UPnP中的协议实现，最后会使用Intel的Linux开发包实现一个 UPnP设备。
随着越来越多的设备联入网络，对于共享设备以及共享设备提供的资源和服务的需求也越来越强烈，透明的访问各种联入网络的资源也成为 了一种非常复杂的任务。因此，在1999年，Microsoft公司开始大张旗鼓地宣传下一代即插即用技术--通用即插即用（ Universal Plug and Play，简称UPnP）。UPnP实际上是 扩展了传统单机的设备和计算机系统的概念，在"零配置"的前提下提供了连网设备之间的发现、接口声明和其他信息的交换等互动操作功 能。Microsoft公司称"UPnP将延伸到家庭中的每一个设备，它会成为个人电脑、应用程序、智能设备集成工作所必需的框架、 协议和接口标准"。
UPnP是实现智能设备端到端网络连接的结构。它也是一种架构在TCP/IP和HTTP技术之上的，分布式、开放的网络结构，以使 得在联网的设备间传递控制和数据。UPnP 技术实现了 控制点、 设备和 服务之间通讯的支持，并且 设备和相关服务的也使用XML定义并且公布出来。使用UPnP，设备可以动态加入网络，自动获得一个IP地址，向其他设备公布它的能 力或者获知其他设备的存在和服务，所有这些过程都是自动完成的，此后设备能够彼此直接通讯。
UPnP不需要设备驱动程序，因此使用UPnP建立的网络是介质无关的。同时UPnP使用标准的TCP/IP和网络协议，使它能够 无缝的融入现有网络。构造UPnP应用程序时可以使用任何语言，并在任何操作系统平台上编译运行。对于设备的描述，使用HTML表单 表述设备控制界面。它既允许设备供应商提供基于浏览器的用户界面和编程控制接口，也允许开发人员定制自己的设备界面。
随着PC成为网络的中心并提供日益丰富的介质和连接服务，在设备与PC相连之后，越来越多的应用将被开发出来。下面的例子只是其中 很小的一部分：
- 智能家庭网络
许多智能家居环境使用了现存的家庭控制网络，例如X10网络来控制和监控整个家居环境，比如灯光，安防和其他家庭设备。这些网络 可以连接PC上，但是除了PC之外，不能被其他的设备存取。使用UPnP设备可以桥接这些网络成为一个网络，并提供用户更多设备 存取家庭网络中的设备。在实现时也无须对X10网络中的现有布线和设备进行昂贵的升级，只需要将设备变成UPnP设备并能够与控 制点通讯并接受控制点的控制命令。 - 数字音频文件管理
可以在PC和其他设备上播放的数字化音频文件在近几年正在成指数级的增长。一个家庭中，可能有几台计算机或者其他设备用于保存这 些音频文件。使用UPnP可以使这些分布在不同PC上的音乐库被统一的管理。这些设备能被发现然后被其他控制点（比如个人电脑、 UPnP接收器）控制。同时这些控制点也可以控制家庭中的任何一个扬声器。 - 数字图片库
许多家庭使用数字相机拍照，或者将已有照片扫描保存，然后将这些照片上载到他们的计算机中保存。在计算机中对其进行分类，或者以 幻灯片的形式进行显示。随着照片的增加，照片可能保存在多种设备或者多种介质上，比如光盘、硬盘、Flash卡。使用UPnP技 术，图片库可以自己作为一个设备存在，并自动在网络上声明。这使得一个照片库可能临时为多个应用程序使用，例如可以进行幻灯片显 示的同时，在电子像框、机顶盒和电视上进行显示。
- Auto-IP
在Ipv4网络中自动选择一个IP地址。你可以访问IETF文档， http://search.ietf.org/internet-drafts/draft-ietf-dhc-ipv4-autoconfig-05.txt。 - DHCP
动态主机控制协议，可以访问 RFC 2131获得更 详细的信息。 - HTTPMU
在UDP上实现HTTP协议的多址传送。 - HTTPU
在UDP上实现普通的HTTP传送协议。 - SOAP
简单对象存取协议（Simple Object Access Protocol ），它是一种应用程序之间进行数据通讯的机制。它是一种在HTTP上使用XML发送命令并接收值的远程过程调用。 - UPC
通用产品编码的缩写（Universal Product Code），它由12个数字构成，由统一编码委员会（Uniform Code Council）管理。这个值可由UPnP制造商指定。 - 单一设备名（UDN）
单一设备名（Unique Device Name）基于UUID，每个表示一个设备。在不同的时间，对于同一个设备此值应该是唯一的。 - 设备
设备是指其他服务或者是设备的容器。一个设备可以包含其他的逻辑设备。 - 设备描述
设备描述包含一个物理设备上所有设备一系列通用属性，它包括服务，设备结构和设备属性。 - 设备类型
设备类型的一般格式为 urn:schemas-upnp-org:device:uuid- device，uuid-device 为UPnP工作委员会定义的标准设备类型。在UPnP设备模版和 设备类型之间是一一对应的，设备制造商也可以指定其他的名字，一般格式为 urn:domain- name:device:uuid-device， uuid-device为制造商定义的标准设备类 型，domain-name字段为设备制造商注册的域名。 - 根设备
根设备是指处于设备树最顶层的设备。 - 控制点
控制点是一个控制器，它可以检索设备和服务描述，发送动作到服务，查询服务的状态变量和从服务接收事件。允许用户使用或运行一个 设备，例如CD播放机，的程序可以认为是控制点。 - 动作
表示客户端发出的完成特定功能的命令。 - 事件
事件是指服务的状态变量的一个或多个改变的通知。 - 事件变量
事件变量是指在改变一个服务的状态变量时触发事件的变量。任何订阅此变量的事件源的控制点将接收到改变通知。非事件变量与事件通 知没有关系。 - 服务
服务是一个逻辑功能单位，服务代表动作和使用状态变量的物理设备的部分或所有状态。 - 服务描述
服务描述是指设备提供的一系列动作以及和动作相关的状态变量。 - 服务类型
服务类型是表示服务的统一资源名。服务类型和UPnP服务模版之间是一一对应的。UPnP任务组定义了几种标准的服务类型。服务 类型的一般格式为： urn:schemas-upnp-org:service:serviceType:version。 例如，扫描仪的服务类型应该为 urn:schemas-upnp-org:service:scanner:1。 UPnP设备制造商可以指定附加服务，这样的服务一般格式为：urn:domain-name:service:serviceType:version ， domain-name字段为设备制造商注册的域名。 - 状态变量
状态变量是用于描述服务状态的数据片断。
UPnP定义了设备之间、设备和控制点、控制点之间通讯的协议。完整的UPnP由设备寻址、设备发现、设备描述、设备控制、事件通 知和基于Html的描述界面几部分构成。UPnP设备协议栈如下图所示:
在最高层中仅包含UPnP制造商定义的特定设备信息，紧接着UPnP工作组定义的内容补充制造商信息。从这层往下，定义的消息为 UPnP特定的消息。也就是说，这些消息定义为以下几个协议：简单设备发现协议（Simple Service Discovery Protocol ），通用事件通知结构（General Event Notification Architecture）和 简单对象存取协议（Simple Object Access Protocol）。这些消息使用 HTTPU或者 HTTPMU发送。这几个 部分在UPnP中的层次关系如下图所示：
UPnP网络的基础就是TCP/IP协议族，UPnP设备能在TCP/IP协议下工作的关键就是正确的设备寻址。一个UPnP设备 寻址的一般过程是：首先向 DHCP服务器发送 DHCPDISCOVER消息，如果在指定的时间内，设备没有收到DHCPOFFERS回应消息，设备必须使用 Auto-IP完成IP地 址的设置。使用Auto-IP时，设备在地址范围169.254/169.16范围中查找空闲的地址。在选中一个地址之后，设备测试 此地址是否在使用。如果此地址被占用，则重复查找过程直到找到一个未被占用的地址，此过程的执行需要底层操作系统的支持，地址的选择 过程应该是随机的以避免多个设备选择地址时发生多次冲突。为了测试选择的地址是否未被占用，设备必须使用地址分辨协议（ARP）。一 个ARP查询请求设置发送者的硬件地址为设备的硬件地址，发送者的IP地址为全0。设备应该侦听ARP查询响应，或者是否存在具有相 同IP地址的ARP查询请求。如果发现，设备必须尝试新的地址。
使用Auto IP的设备必须定时检测DHCP服务器是否存在，这可以通过定时发送DHCPDISCOVER消息实现，如果接收到DHCPOFFERS回应消息，设备必 须释放Auto IP分配的地址，此时设备必须取消所有的广告消息并重新发出新的。
一个设备可以使用UPnP之外的更高层的协议，这些协议将为设备使用友好的名称。在这种情况下，将这些友好的主机名解析为IP地址 就很必要了，DNS通常是用来实现此功能的。使用此功能的设备可能要包含一个DNS客户端，而且支持动态的DNS注册，通过注册将它 自己的名字加入到地址分布图中。
一旦设备连接到网上并且分配了地址，就要进行发现的操作了。设备发现是UPnP网络实现的第一步。设备发现是由简单发现协议 SSDP（Simple Service Discovery Protocol）来定义的。在设备发现操作之后，控制点可以发现感兴趣的设备，并使得控制点获得设备能力的描述，同时控制点也可以向设备发送命令，侦听 设备状态的改变，并将设备展示给用户。
当一个设备加入到网络中，设备发现过程允许设备向网络上的控制点告知它提供的服务。当一个控制点加入到网络中时，设备发现过程允许 控制点寻找网络上感兴趣的设备。在这两种情况下，基本的交换信息就是发现消息。发现消息包括设备的一些特定信息或者某项服务的信息， 例如它的类型、标识符、和指向XML设备描述文档的指针。
在一个新设备加入网络时，如果它存在多个嵌入设备，那么它将多目传送一系列发现消息公开它的设备和服务。任何感兴趣的控制点可以在 此标准的多目地址上监听新服务可用通知消息。同样，在一个控制点加入网络时，它多目传送发现消息寻找相关设备或服务。所有的设备必须 在标准多目传送地址上监听这些消息并且存在匹配的设备或服务时自动响应发现消息。在设备从网络中除去时，它也应该发出一系列声明，表 示此设备包含的设备和服务已经失效。下图表示设备和控制点交互的一般过程：
简单发现协议（SSDP）定义了在网络中发现网络服务，控制点定位网络上相关资源和设备在网络上声明其可用性的方法。它是建立在 HTTPU和 HTTPMU的基础上的， 用于控制设备发送声明和离开消息，以及控制点发送的查询消息实现设备发现操作的。简单发现协议使用租用模型减少了本来是必需的系统开 销，网络上的每一个控制点拥有网络状态的全部信息并保持着网络较低的通讯量。为了增加租用模型的健壮性，简单发现协议通过定期发送声 明消息的办法保证在设备超时决定设备是否可以使用。缺省的声明消息租用时间是30分钟。
UPnP网络结构的第二步是设备描述。在控制点发现了一个设备之后，控制点仍然对设备知之甚少，控制点可能仅仅知道设备或服务的 UPnP类型，设备的UUID和设备描述的URL地址。为了让控制点更多的了解设备和它的功能或者与设备交互，控制点必须从发现消息 中得到设备描述的URL，通过URL取回设备描述。设备描述的一般过程：
对于一个设备的UPnP描述一般分成两个部分：描述设备和描述设备提供的服务。UPnP对某一设备的描述以XML形式表示出来，设 备描述包括制造商信息，包括模块名称和编号，序列号，制造商名称，制造商网站的URL等等。设备描述也包括所有嵌入设备描述和URL 地址集。对于一个物理设备可以包含多个逻辑设备，多个逻辑设备既可以是一个根设备其中嵌入多个设备，也可以是多个根设备的方式实现。 设备描述是由设备制造商提供的，采用XML表述，并且遵循UPnP设备模版。此模版是由UPnP工作委员会生成的。
UPnP服务描述包括一系列命令或者动作，服务响应，动作的参数。服务的描述也包含一系列变量，这些变量描述了服务运行时刻的状 态，这包括数据类型、取值范围和事件特性的描述。服务描述也是由设备制造商提供的，采用XML方式表述，遵循UPnP服务模版。
设备控制是UPnP网络的第三步。在接收设备和服务描述之后，控制点可以向这些服务发出动作，同时控制点也可以轮询服务的状态变量 值。发出动作实质上是一种远程过程调用，控制点将动作送到设备服务，在动作完成之后，服务返回相应的结果。设备控制的一般过程如下 图：
为了控制一个设备，控制点向设备服务发出一个动作。这一般通过向服务的控制URL地址发送一个适当的控制消息，而服务则做出相应的 响应。动作的效果可以通过改变一个描述服务运行状态的变量。在这些状态变量改变时，时间将发送到所有相关的控制点。控制点也会轮询服 务的状态变量值以获得状态变量的当前值，与发出一个动作的过程相似，控制点向服务的控制URL发送一个适当的查询消息，而服务则返回 相应的变量值。每个服务必须保持状态变量的一致性，以便控制点能够轮询并接收到有意义的值。
设备事件是UPnP网络的第四步。一个服务的UPnP描述包括服务响应的动作列表和运行时模拟服务状态的变量列表。当这些变量改变 时，服务就会发布更新，则控制点就会收到设备事件。设备事件发送的一般过程如下图：
为了订阅事件，订阅者发送一个订阅消息。如果出版者收到此消息，它将以这个订阅的持续时间作为响应。为了保持订阅，订阅者必须在订 阅到期之前进行续订。在订阅者不需要出版者发送的事件时，订阅者必须取消这个订阅。出版者通过发送事件消息提醒订阅者状态变量改变。 事件消息包含多个状态变量的名字和这些变量的当前值。在订阅者第一次订阅时，需要发送初始化事件消息，这个事件包含所有事件变量的名 和值并且允许订阅者出示化服务变量值。为了支持多个控制点，在动作生效之后所有订阅者都将接到通知。事件消息使用HTTP协议传送， 事件详细定义在通用事件通知结构（General Event Notification Architecture）协议中。
设备表征是UPnP设备的最后一步。如果设备有表征的URL，那么控制点就能通过URL得到页面，在浏览器中装载页面，并使得用户 根据页面提供的功能控制设备或者浏览设备状态。它具体能完成到什么与设备和表征页面的功能有关。
设备表征包含在设备描述的presentationURL字段。设备表征可以完全由设备制造商提供，它采用HTML页的形式，使用 HTTP进行发布。
UPnP协议的设备发现过程使用简单服务发现协议（Simple Service Discovery Protocol），此协议为网络客户提供一种无需任何配置、管理和维护网络上设备服务的机制。此协议采用基于通知和发现路由的多播发现方式实现。协议客 户端在保留的多播地址239.255.255.250发现服务，同时每个设备服务也在此地址上监听服务发现请求。如果服务监听到的发 现请求与此服务相匹配，此服务会使用单播方式响应。每个服务也可以向多播端口发送通知声明服务存在。
常见的协议请求消息有两种类型，第一种是服务通知，设备和服务使用此类通知消息声明自己存在；第二种是查询请求，协议客户端用此请 求查询某种类型的设备和服务。请求消息中包含设备的特定信息或者某项服务的信息，例如设备类型、标识符和指向设备描述文档的URL地 址。下图显示这两类通知消息和HTTP协议的关系：
设备发现过程允许控制点使用一个设备类型或标识，或者是服务类型进行查询。这要求标准设备或服务类型，或者设备特定实例的发现和广 告消息基于一个独一无二的标识，UPnP设备和服务类型的定义是UPnP论坛工作委员会的责任。从设备获得响应的内容基本上与多址传 送的设备广播相同，只是采用单址传送方式。
HTTP（Hyper Text Transfer Protocol）是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP协议的详细内容请参考RFC 2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内 容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、 实体元信息以及可能的实体内容。
通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一 个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号 （:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个 空格或制表符。
通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、Connection、Date、 Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在 不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。
2.1.1 Cache-Control头域
Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一 个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、 min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各个 消息中的指令含义如下：
| Public | 指示响应可被任何缓存区缓存。 |
| Private | 指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消 息对于其他用户的请求无效。 |
| no-cache | 指示请求或响应消息不能缓存 |
| no-store | 用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。 |
| max-age | 指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。 |
| min-fresh | 指示客户机可以接收响应时间小于当前时间加上指定时间的响应。 |
| max-stale | 指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指 定值之内的响应消息。 |
2.1.2 Date头域
Date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如， Date: Mon, 31 Dec 2001 04:25:57 GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
2.1.3 Pragma头域
Pragma头域用来包含实现特定的指令，最常用的是Pragma: no-cache。在HTTP/1.1协议中，它的含义和Cache-Control: no-cache相同。
请求消息的第一行为下面的格式：
Method SP Request-URI SP HTTP-Version CRLF Method表示对于Request-URI完成的方法，这个字段是大小写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、 DELETE、TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持，其他所有方法的实现是可选的。GET方法取回由 Request-URI标识的信息。HEAD方法也是取回由Request-URI标识的信息，只是可以在响应时，不返回消息体。 POST方法可以请求服务器接收包含在请求中的实体信息，可以用于提交表单，向新闻组、BBS、邮件群组和数据库发送消息。
SP表示空格。Request-URI遵循URI格式，在此字段为星号（*）时，说明请求并不用于某个特定的资源地址，而是用于服 务器本身。HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。CRLF表示换行回车符。请求头域允许客户端 向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段Accept、Accept-Charset、 Accept-Encoding、Accept-Language、Authorization、From、Host、If- Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If- Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、 Referer、User-Agent。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处 理。
典型的请求消息：
|
上例第一行表示HTTP客户端（可能是浏览器、下载程序）通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息， 绿色的部分表示通用头部分。
2.2.1 Host头域
Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须 包含主机头域，否则系统会以400状态码返回。
2.2.2 Referer头域
Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允 许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分 uri地址，则此地址应该是一个相对地址。
2.2.3 Range头域
Range头域可以请求实体的一个或者多个子范围。例如，
表示头500个字节： bytes = 0 - 499表示第二个500字节： bytes = 500 - 999表示最后500个字节： bytes = -500表示500字节以后的范围： bytes = 500-第一个和最后一个字节： bytes = 0-0 , -1同时指定几个范围： bytes = 500-600, 601-999
但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（Partial Content）返回而不是以200（OK）。
2.2.4 User-Agent头域
User-Agent头域的内容包含发出请求的用户信息。
响应消息的第一行为下面的格式：
|
HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。Status-Code是一个三个数字的结果代码。 Reason-Phrase给Status-Code提供一个简单的文本描述。Status-Code主要用于机器自动识 别，Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别，后两个数字没有分类的作 用。第一个数字可能取5个不同的值：
1xx : 信息响应类，表示接收到请求并且继续处理
2xx : 处理成功响应类，表示动作被成功接收、理解和接受
3xx : 重定向响应类，为了完成指定的动作，必须接受进一步处理
4xx : 客户端错误，客户请求包含语法错误或者是不能正确执行
5xx : 服务端错误，服务器不能正确执行一个正确的请求
响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包 含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、 Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头域，一 般将会作为实体头域处理。
典型的响应消息：
|
上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息，绿色的部分表示通用头部分，红色的部分表示实体 头域的信息。
2.3.1 Location响应头
Location响应头用于重定向接收者到一个新URI地址。
2.3.2 Server响应头
Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。
请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括 Allow、Content-Base、Content-Encoding、Content-Language、Content- Length、Content-Location、Content-MD5、Content-Range、Content- Type、Etag、Expires、Last-Modified、extension-header。extension- header允许客户端定义新的实体头，但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流，它的编码方式由 Content-Encoding或Content-Type定义，它的长度由Content-Length或Content- Range定义。
2.4.1 Content-Type实体头
Content-Type实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的 请求介质类型。
2.4.2 Content-Range实体头
Content-Range实体头用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分 响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：
|
例如，传送头500个字节次字段的形式：Content-Range: bytes 0-499/1234 如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围，Content- Length表示实际传送的字节数。
2.4.3 Last-modified实体头
Last-modified实体头指定服务器上保存内容的最后修订时间。
在设备加入网络，UPnP发现协议允许设备向控制点广告它的服务。它使用向一个标准地址和端口多址传送发现消息来实现。控制点在此 端口上侦听是否有新服务加入系统。为了通知所有设备，一个设备为每个其上的嵌入设备和服务发送一系列相应的发现消息。每个消息也包含 它表征设备或服务的特定信息。
3.1.1 ssdp:alive消息
在设备加入系统时，它采用多播传送方式发送发现消息，包括告知设备包含的根设备信息，所有嵌入设备以及它包含的服务。每个发现消息 包含四个主要对象：
- 在NT头中包含的潜在搜索目标。
- 在USN头中包含的复合发现标识
- 在LOCATION头中关于设备信息的URL地址
- 在CACHE-CONTROL头中表示的广告消息的合法存在时间。
对于根设备，存在三种发现消息：
| NT | USN |
| 根设备的UUID | 根设备的UUID |
| 设备类型：设备版本 | 根设备的UUID，设备类型：设备版本 |
| upnp:rootdevice | 根设备的UUID，设备类型和upnp:rootdevice |
对于根设备，存在两种发现消息：
| NT | USN |
| 嵌入设备的UUID | 嵌入设备的UUID |
| 设备类型：设备版本 | 嵌入设备的UUID，设备类型和设备版本 |
对于每个服务：
| NT | USN |
| 服务类型：服务版本 | 相关设备的UUID，服务类型和服务版本 |
如果一个根设备有n个嵌入设备，m个嵌入服务，而且包含k个不同的服务类型，这将会发出3 + 2n + k次请求。这些广告消息像控制点描述了设备的所有信息。这些消息必须作为一系列一起发出，发送的顺序无关紧要，但是不能对单个消息进行刷新或取消的操作。 选择一个适当的持续期是在最小化网络通讯和最大化设备状态及时更新之间求得一个平衡，相对较短的持续时间可以保证控制点在牺牲网络流 量的前提下获得设备的当前状态；持续期越长可以大大减少设备刷新造成的网络流量。一般而言，设备制造商应该选择一个适当的持续时间 值。
由于UDP协议是不可信的，设备应该发送多次设备发现消息。而且为了降低控制点无法收到设备或服务广告消息的可能性，设备应该定期 发送它的广告消息。在设备加入网络时，它必须用NOTIFY方法发送一个多播传送请求。NOTIFY方法发送的请求没有回应消息，典 型的设备通知消息格式如下：
|
各HTTP协议头的含义简介：
| HOST | 设置为协议保留多播地址和端口，必须是239.255.255.250:1900。 |
| CACHE-CONTROL | max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在 |
| LOCATION | 包含根设备描述得URL地址 |
| NT | 在此消息中，NT头必须为服务的服务类型。 |
| NTS | 表示通知消息的子类型，必须为ssdp:alive |
| USN | 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。 |
一个发现响应可以包含0个、1个或者多个服务类型实例。为了做出分辨，每个服务发现响应包括一个USN：根设备的标识。在同样的设 备里，一个服务类型的多个实例必须用包含USN:ID的服务标识符标识出来。例如，一个灯和电源共用一个开关设备，对于开关服务的查 询可能无法分辨出这是用于灯的。UPNP论坛工作组通过定义适当的设备层次以及设备和服务的类型标识分辨出服务的应用程序场景。这么 做的缺点是需要依赖设备的描述URL。
3.1.2 ssdp:byebye消息
在设备和它的服务将要从网络中卸载时，设备应该对于每个未超期的ssdp:alive消息多播方式传送ssdp:byebye消 息。但如果设备突然从网络卸载，它可能来不及发出这个通知消息。因此，发现消息必须在CACHE-CONTROL包含超时值，如果不 重新发出广告消息，发现消息最后超时并从控制点的缓存中除去。典型的设备卸载消息格式如下：
|
当一个控制点加入到网络中时，设备发现过程允许控制点寻找网络上感兴趣的设备。发现消息包括设备的一些特定信息或者某项服务的信 息，例如它的类型、标识符、和指向XML设备描述文档的指针。从设备获得响应从本质上说，内容与多址传送的设备广播相同，只是采用单 址传送方式。设备查询通过HTTP协议扩展M-SEARCH方法实现的。典型的设备查询请求消息格式：
|
各HTTP协议头的含义简介：
| HOST | 设置为协议保留多播地址和端口，必须是239.255.255.250:1900。 |
| MAN | 设置协议查询的类型，必须是"ssdp:discover"。 |
| MX | 设置设备响应最长等待时间，设备响应在0和这个值之间随机选择响应延迟的值。这样可以为控制点响应平衡网络负载。 |
| ST | 设置服务查询的目标，它必须是下面的类型： 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字段值）与此设备匹配时，设备必须向多播地址239.255.255.250:1900回 应响应消息。典型：
|
各HTTP协议头的含义简介：
| CACHE-CONTROL | max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在 |
| DATE | 指定响应生成的时间 |
| EXT | 向控制点确认MAN头域已经被设备理解 |
| LOCATION | 包含根设备描述得URL地址 |
| SERVER | 饱含操作系统名，版本，产品名和产品版本信息 |
| ST | 内容和意义与查询请求的相应字段相同 |
| USN | 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。 |
在所有的发现通知中，表示UPnP根设备描述的LOCATION和统一服务名(USN)必须提供。此外，在响应消息中查询目标头 (ST)必须与LOCATION和统一服务名(USN)一起提供。
专有设备或服务可以不遵循标准的UPNP模版。但如果设备或服务提供UPNP发现、描述、控制和事件过程的所有对象，它的行为就像 一个标准的UPNP设备或服务。为了避免命名冲突，使用专有设备命名时除了UPNP域之外必须包含一个前 缀"urn:schemas-upnp-org"。在与标准模版相同时，应该使用整数版本号。但如果与标准模版不同，不可以使用设备 复用和徽标。
简单设备发现协议不提供高级的查询功能，也就是说，不能完成某个具有某种服务的设备这样的复合查询。在完成设备或者服务发现之后， 控制点可以通过设备或服务描述的URL地址完成更为精确的信息查询。
参 考资料
RFC 2616:
关于超文本传输协议（HTTP 1.1）原文IETF的RFC文档 http://www.ietf.org/rfc/rfc2616.txt?number=2616
SSDP协议:
简单服务发现协议，协议原文参考 http://www.upnp.org/download/draft_cai_ssdp_v1_03.txt
GENA:
通用事件通知结构，协议原文参考 http://www.upnp.org/download/draft-cohen-gena-client-01.txt
HTTPU和HTTPMU:
在UDP上实现HTTP协议传送以及HTTP协议多址传送。协议规范参考 http://www.upnp.org/download/draft-goland-http-udp-04.txt
第四章
台式机迁移笔记本
2015年08月18日18:52:59
没有评论 :
发表评论