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应当重传前次的请求;

 

你可能感兴趣的:(UPnP DeviceArchitecure Step 2 : Description)