关于Upnp的散乱记录

最近在看关于upnp相关协议，大概理解了一下，迟点再补充其中的内容，下面是一些简单的记录，比较乱，有空在整理，归纳一遍，暂时先放着。
 
1 ssdp协议
 
1 discovery requests, a SSDP client looking for SSDP services.
2 presence announcements, a SSDP service announcing its presence.
 
Why use multicast for communication?
 
Why use a local administrative scope multicast address?
 
Why does SSDP support both service discovery requests as well as service presence announcements?
 
SSDP decided to adopt a hybrid approach and do both discovery and
   announcements. This can be incredibly efficient. When a service
   first comes on-line it will send out an announcement so that
   everyone knows it is there. At that point it shouldn't ever need to
   send out another announcement unless it is going off-line, has
   changed state or its cache entry is about to expire. Any clients who
   come on-line after the service came on-line will discover the
   desired service by sending out a discovery request. The client
   should never need to repeat the discovery request because any
   services that subsequently come on-line will announce themselves.
   The end result is that no one needs to send out steady streams of
   messages. The entire system is event driven, only when things change
   will messages need to be sent out. The cost, however, is that the
   protocol is more complex. We felt this was a price worth paying as
   it meant that SSDP could be used successfully in fairly large
   networks.
 
上线通知，一直到“going off-line, has changed state or its cache entry is about to expire“再通知
如果client上线比服务迟，则当期需要服务时，就发送discovery request
 
If a SSDP service hears a HTTP UDP discovery request that
   matches the service it offers then it will respond using a unicast
   HTTP UDP response.（组播出，单播回）
 
draft-goland-http-udp-00.txt
 
设备发现交互信息
   USN URI          | Service Type URI | Expiration | Location
   -----------------|------------------|------------|------------------
   upnp:uuid:k91... | upnp:clockradio  | 3 days     | http://foo.com/cr
   -----------------|------------------|------------|------------------
   uuid:x7z...      | ms:wince         | 1 week     | http://msce/win
  Location
设备描述文件
（获取此文件通过TCP HTTP协议 GET命令）
 
 
对于一个设备的UPnP描述一般分成两个部分：描述设备和描述设备提供的服务。UPnP对某一设备的描述以XML形式表示出来，设备描述包括制造商信息，包括模块名称和编号，序列号，制造商名称，制造商网站的URL等等。设备描述也包括所有嵌入设备描述和URL地址集。对于一个物理设备可以包含多个逻辑设备，多个逻辑设备既可以是一个根设备其中嵌入多个设备，也可以是多个根设备的方式实现。设备描述是由设备制造商提供的，采用XML表述，并且遵循UPnP设备模版。此模版是由UPnP工作委员会生成的。
UPnP服务描述包括一系列命令或者动作，服务响应，动作的参数。服务的描述也包含一系列变量，这些变量描述了服务运行时刻的状态，这包括数据类型、取值范围和事件特性的描述。服务描述也是由设备制造商提供的，采用XML方式表述，遵循UPnP服务模版。
 
获得文档后可以实现控制
(SOAP协议 http上TCP传输 post命令)
SOAP类似与COM技术 使用xml作为控制文档来发送请求
 
 
 
Upnp技术：

 
 
主要包括：
寻址，设备发现，设备描述，设备控制，事件订阅；
寻址可以有静态ip ，动态ip，autoip（不存在DHCP服务器时） 技术获得ip地址；
 
设备发现采用ssdp协议；
Ssdp 分为几个方面：
1：上线通知，组播地址239：255：255：250 端口1900，主要发送自己的设备信息以及服务信息；（no response）
2：查找服务,z组播需要查找的服务，当本机有匹配的服务时，单播设备信息及服务信息回应；
3：ssdp中有一个域是描述expire时间，当时间过去时，需要在本机cache中删除服务的信息，；
4，设备会在一定时间内announcement自己的服务，以确保自己的存在，同时由于使用udp传输，所以不确定所有设备都收到自己的设备信息；
 
当设备需要服务时，可以通过http tcp链接获取设备的服务文档url，以及响应的控制信息；
 
通过url，设备可以对需要控制的设备发送命令，此时遵守的是soap协议：
Soap协议是一种webservice服务，上层利用http，tcp协议传输，xml文件做控制描述（个人理解是远程调用函数，只是函数封装在服务器端，需要http post命令，而响应时返回ok命令）通过client端向服务器端发送命令，服务器端响应client的post命令，并返回响应信息，具体可以参考webservice soap编程；
 
另外需要利用soap利用http协议传输的一个原因是防止防火墙的过滤，http利用默认端口80传输，防火墙一般不对此进行过滤。