UPnP DeviceArchitecure Step 2 : Description

要点记录

一、概要

1、Description在逻辑上分为两部分：

    a）device description：用来描述物理/逻辑上的容器；

    b）service description：device所能提供的服务；

2、一个物理设备可以包含多个逻辑设备，多个逻辑设备能够被看作带有多个embeded services的root device，也可以被看作是单个的root device（可以没有对应的embeded service），最新的case是按照后一种情况对待：存在多个UPnP device description，每一个对应一个单独的root device；

3、如前所述，UPnP的版本号分为major和minor两部分，major version相同的情况下，必须保证向后兼容，不同的情况下则不保证向后兼容；

4、Device和service的版本号在概念上不同于UPnP版本号，它可以由UPnP工作组标准化，也可以由vendor定义，在开发阶段，可以是非整数的格式，产品化之后必须定义为整数格式。device和service type的版本号上升时，必须确保device包含低版本所有的embeded devices和services（向后兼容），如果版本号上升时，不能确保向后兼容，则device和service的name需要更新，同时对应的版本号需要重置为1。

5、Device type和service type是一个“building block”的概念。Standard或是vendor-defined的device type可以被封装在standard或vendor-defined的device type内，service type也是一样。CP需要具备在任何可能的device type（无论该CP是否能够识别）内识别出自己需要的service type；

6、注意multi-homed和UPnP-enabled interfaces的概念，这是DA1.1和DA1.0有区别的地方。（DMS多网卡（场景是什么）？old IP address尚未过期，new IP address已经启用？）

二、Device description

1、紧跟"device:"的device type后缀应当小于64个字符；

2、friendlyName和manufacturer应当小于64个字符；

3、modelDescription应当小于128个字符；

4、modelName和modelNumber应当小于32个字符；

5、URLBase域不再被推荐使用；

6、serialNubmer应当小于64个字符；

7、对于不能识别的element、attribute以及对应的sub elements和values，devices和CPs应当忽略；

8、Device description的编码方式应为UTF-8；

三、UPnP Device Template

四、Service description

    需要关注一下扩展data types的定义和处理。

五、UPnP Service Template

六、Non-standard vendor extensions and limitations

七、UPnP Device Schema

八、UPnP Service Schema

九、UPnP Datatype Schema

十、Retrieving a description using HTTP

    1、Description的基于HTTP+TCP的方式，注意和Discovery的区别；

    2、CP请求description之后，device需要在30s内回应，否则CP应当重传前次的请求；