UPnP 2.0架构详解：设备发现与控制

upnp

architecture

需积分: 10 150 浏览量更新于2024-07-21 收藏 1.86MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"UPnP 2.0 英文文档详细阐述了UPnP架构的五个基本阶段，并提供了关于UPnP设备架构2.0的详细信息。文档修订日期为2015年2月20日，由UPnP论坛发布。" 在深入探讨UPnP 2.0之前，我们首先理解一下UPnP是什么。通用即插即用（Universal Plug and Play，UPnP）是一种网络通信协议，旨在简化设备间的互联和交互，特别是智能家居、物联网(IoT)设备等。它允许设备自动在网络中发现并相互操作，无需手动配置。 1. **发现(Discovery)**：在这个阶段，UPnP设备会通过广播网络上的信息，让其他设备知道它们的存在和提供的服务。控制点（如智能手机、电脑等）监听这些广播，寻找感兴趣的设备和服务。 2. **描述(Description)**：一旦控制点找到感兴趣的设备，它会请求获取设备的详细描述，包括设备类型、制造商信息、提供的服务列表等。这些信息通常以XML格式的设备描述文件提供。 3. **控制(Control)**：在控制阶段，控制点能够通过HTTP或SOAP（简单对象访问协议）消息与设备交互，改变设备状态或执行特定操作。例如，用户可以通过手机控制智能灯泡的开关和亮度。 4. **事件(Eventing)**：事件通知机制确保控制点能实时了解设备状态的变化。设备会在状态变化时发送事件通知，控制点通过订阅这些事件来保持同步。 5. **表示(Presentation)**：表示阶段涉及设备提供一个用户界面，通常以HTML形式，使得用户可以直接通过网页来操作设备。这增强了用户的交互体验，使控制更为直观。 UPnP 2.0在原有的基础上可能引入了新的特性和改进，以适应不断发展的物联网环境。例如，可能增加了对新设备类型的支持，提高了安全性，或者优化了网络通信效率。然而，文档中的法律条款强调，UPnP论坛不对任何潜在的知识产权问题负责，并明确表示提供的框架“按原样”提供，不包含任何明示或暗示的保证。 UPnP 2.0是实现设备自动化发现、控制和协同工作的一种关键技术，对于构建智能、自组织的网络环境至关重要。通过理解和应用UPnP 2.0的原理，开发者和制造商能够创建更加无缝集成的家庭和商业网络解决方案。

资源详情

资源推荐

— 15 —

Defined by a UPnP Forum working committee. One-to-one relationship with standard service

types. For more information, see clause 2, “Description”.

UPnP Device Schema

Defines the elements and attributes used in UPnP Device and Service Templates. Written in

XML syntax and derived from XML Schema (Part 1: Structures, Part 2: Datatypes). Defined by

the UPnP Device Architecture herein. For more information, see clause 2, “Description”.

Vendor Domain Name

A domain name that is supplied by a vendor. It is owned by the vendor, and shall be

registered with an ICANN accredited Registrar, such that it is unique. The vendor shall keep

the domain name registration up to date. A Vendor Domain Name length should be chosen to

be compatible with the use of the domain name in the UDA.

References and resources

RFC 2710, Multicast Listener Discovery for IPv6. Available at:

http://www.ietf.org/rfc/rfc2710.txt.

RFC 2616, HTTP: Hypertext Transfer Protocol 1.1. Available at:

http://www.ietf.org/rfc/rfc2616.txt.

RFC 2279, UTF-8, a transformation format of ISO 10646 (character encoding). Available at:

http://www.ietf.org/rfc/rfc2279.txt.

XML, Extensible Markup Language. W3C recommendation. Available at:

http://www.w3.org/XML/.

DEVICEPROTECTION, UPnP Device Protection specification. Available at

http://upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service.pdf.

Each clause in this document contains additional information about resources for specific

topics.

0 Addressing

Addressing is Step 0 of UPnP networking. Through addressing, devices and control points get

a network address. Addressing enables discovery (Step 1) where control points find

interesting device(s), description (Step 2) where control points learn about device capabilities,

control (Step 3) where a control point sends commands to device(s), eventing (Step 4) where

control points listen to state changes in device(s), and presentation (Step 5) where control

points display a user interface for device(s).

The foundation for UPnP networking is IP addressing. A UPnP device or control point is

allowed to support IP version 4-only, or both IP version 4 and IP version 6. This clause, and

the examples given throughout clauses 1 through 5 of this document, assumes an IPv4

implementation. Annex A of this document describes IPv6 operation. Each UPnP device or

control point which does not itself implement a DHCP server shall have a Dynamic Host

Configuration Protocol (DHCP) client and search for a DHCP server when the device or

control point is first connected to the network (if the device or control point itself implements a

DHCP server, it allowed to allocate itself an address from the pool that it controls). If a DHCP

server is available, i.e., the network is managed; the device or control point shall use the IP

address assigned to it. If no DHCP server is available, i.e., the network is unmanaged; the

device or control point shall use automatic IP addressing (Auto-IP) to obtain an address.

Auto-IP (defined in RFC 3927) defines how a device or control point: (a) determines if DHCP

is unavailable, and (b) intelligently chooses an IP address from a set of link-local IP

addresses. This method of address assignment enables a device or control point to easily

move between managed and unmanaged networks.

— 16 —

This clause provides an overview of the basic operation of Auto-IP. The operations described

in this clause are detailed and clarified in the reference documents listed below. Where

conflicts between this document and the reference documents exist, the reference document

always takes precedence.

0.1 Determining whether to use Auto-IP

A device or control point that supports Auto-IP and is configured for dynamic address

assignment begins by requesting an IP address via DHCP by sending out a DHCPDISCOVER

message. The amount of time this DHCP Client listens for DHCPOFFERs is implementation

dependent. If a DHCPOFFER is received during this time, the device or control point shall

continue the process of dynamic address assignment. If no valid DHCPOFFERs are received,

the device or control point shall then auto-configure an IP address using Auto-IP.

0.2 Choosing an address

To auto-configure an IP address using Auto-IP, the device or control point uses an

implementation dependent algorithm for choosing an address in the 169.254/16 range. The

first and last 256 addresses in this range are reserved and shall NOT be used.

The selected address shall then be tested to determine if the address is already in use. If the

address is in use by another device or control point, another address shall be chosen and

tested, up to an implementation dependent number of retries. The address selection shall be

randomized to avoid collision when multiple devices or control points are attempting to

allocate addresses. The device or control point chooses an address using a pseudo-random

algorithm (distributed over the entire address range from 169.254.1.0 to 169.254.254.255) to

minimize the likelihood that devices or control points that join the network at the same time

will choose the same address and subsequently choose alternative addresses in the same

sequence when collisions are detected. This pseudo-random algorithm should be seeded

using the device’s or control point’s Ethernet hardware MAC address.

0.3 Testing the address

To test the chosen address, the device or control point shall use an Address Resolution

Protocol (ARP) probe. An ARP probe is an ARP request with the device or control point

hardware address used as the sender's hardware address and the sender's IP address set to

0s. The device or control point shall then listen for responses to the ARP probe, or other ARP

probes for the same IP address. If either of these ARP packets is seen, the device or control

point shall consider the address in use and try a different address. The ARP probe is allowed

to be repeated for greater certainty that the address is not already in use; it is recommended

that the probe be sent four times at two-second intervals.

After successfully configuring a link-local address, the device or control point shall send two

gratuitous ARPs, spaced two seconds apart, this time filling in the sender IP address. The

purpose of these gratuitous ARPs is to make sure that other hosts on the net do not have

stale ARP cache entries left over from some other host that may previously have been using

the same address.

Devices and control points that are equipped with persistent storage are allowed to record the

IP address they have selected and on the next boot use that address as their first candidate

when probing, in order to increase the stability of addresses and reduce the need to resolve

address conflicts.

Address collision detection is not limited to the address testing phase, when the device or

control point is sending ARP probes and listening for replies. Address collision detection is an

ongoing process that is in effect for as long as the device or control point is using a link-local

address. At any time, if a device or control point receives an ARP packet with its own IP

address given as the sender IP address, but a sender hardware address that does not match

its own hardware address, then the device or control point shall treat this as an address

collision and shall respond as described in either a) or b) below:

— 17 —

a) Immediately configure a new link-local IP address as described above; or,

b) If the device or control point currently has active TCP connections or other reasons to

prefer to keep the same IP address, and has not seen any other conflicting ARP packets

recently (e.g., within the last ten seconds) then it is allowed to elect to attempt to defend

its address once, by recording the time that the conflicting ARP packet was received, and

then broadcasting one single gratuitous ARP, giving its own IP and hardware addresses

as the source addresses of the ARP. However, if another conflicting ARP packet is

received within a short time after that (e.g., within ten seconds) then the device or control

point shall immediately configure a new Auto-IP address as described above.

The device or control point shall respond to conflicting ARP packets as described in either a)

or b) above; it shall NOT ignore conflicting ARP packets. If a new address is selected, the

device or control point shall cancel previous advertisements and re-advertise with the new

address.

After successfully configuring an Auto-IP address, all subsequent ARP packets (replies as

well as requests) containing an Auto-IP source address shall be sent using link-level

broadcast instead of link-level unicast, in order to facilitate timely detection of duplicate

addresses.

0.4 Forwarding rules

IP packets whose source or destination addresses are in the 169.254/16 range shall NOT be

sent to any router for forwarding. Instead, the senders shall ARP for the destination address

and then send the packets directly to the destination on the same link. IP datagrams with a

multicast destination address and an Auto-IP source address shall NOT be forwarded off the

local link. Devices and control points are allowed to assume that all 169.254/16 destination

addresses are on-link and directly reachable. The 169.254/16 address range shall not be

subnetted.

0.5 Periodic checking for dynamic address availability

A device or control point that has auto-configured an IP address shall periodically check for

the existence of a DHCP server. This is accomplished by sending DHCPDISCOVER

messages. How often this check is made is implementation dependent, but checking every 5

minutes would maintain a balance between network bandwidth required and connectivity

maintenance. If a DHCPOFFER is received, the device or control point shall proceed with

dynamic address allocation. Once a DHCP assigned address is in place, the device or control

point is allowed to release the auto-configured address, but is also allowed to choose to

maintain this address for a period of time (or indefinitely) to maintain connectivity.

To switch over from one IP address to a new one, the device should, if possible, cancel any

outstanding advertisements made on the previous address and shall issue new

advertisements on the new address. The clause on Discovery explains advertisements and

their cancellations. In addition, any event subscriptions are deleted by the device (see clause

on Eventing).

For a multi-homed device with multiple IP addresses, to switch one of the IP addresses to a

new one, the device should cancel any outstanding advertisements made on the previous IP

address, and shall issue new advertisements on the new IP addresses. Furthermore, it shall

also issue appropriate update advertisements on all unaffected IP addresses. The clause on

Discovery explains advertisements, their cancellations and updates. The clause on Eventing

explains the effect on event subscriptions.

0.6 Device naming and DNS interaction

Once a device has a valid IP address for the network, it can be located and referenced on that

network through that address. There may be situations where the end user needs to locate

and identify a device. In these situations, a friendly name for the device is much easier for a

human to use than an IP address. If a device chooses to provide a host name to a DHCP

— 18 —

server and register with a DNS server, the device should either ensure the requested host

name is unique or provide a means for the user to change the requested host name. Most

often, devices do not provide a host name, but provide URLs using literal (numeric) IP

addresses.

Moreover, names are much more static than IP addresses. Clients referring a device by name

don't require any modification when the IP address of a device changes. Mapping of the

device's DNS name to its IP address could be entered into the DNS database manually or

dynamically according to RFC 2136. While devices supporting dynamic DNS updates can

to register DNS records on behalf of these DHCP clients.

0.7 Name to IP address resolution

A device that needs to contact another device identified by a DNS name needs to discover its

IP address. The device submits a DNS query according to RFC1034 and 1035 to the pre-

configured DNS server(s) and receives a response from a DNS server containing the IP

address of the target device. A device can be statically pre-configured with the list of DNS

servers. Alternatively a device could be configured with the list of DNS server through DHCP,

or after the address assignment through a DHCPINFORM message.

0.8 References

RFC1034, Domain Names - Concepts and Facilities. Available at:

http://www.ietf.org/rfc/rfc1034.txt.

RFC1035, Domain Names - Implementation and Specification. Available at:

http://www.ietf.org/rfc/rfc1035.txt.

RFC 2131, Dynamic Host Configuration Protocol. Available at:

http://www.ietf.org/rfc/rfc2131.txt.

RFC 2136, Dynamic Updates in the Domain Name System. Available at:

http://www.ietf.org/rfc/rfc2136.txt.

RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses. Available at:

http://www.ietf.org/rfc/rfc3927.txt.

1 Discovery

Discovery is Step 1 in UPnP™ networking. Discovery comes after addressing (Step 0) where

devices get a network address. Through discovery, control points find interesting device(s).

Discovery enables description (Step 2) where control points learn about device capabilities,

control (Step 3) where a control point sends commands to device(s), eventing (Step 4) where

control points listen to state changes in device(s), and presentation (Step 5) where control

points display a user interface for device(s).

Discovery is the first step in UPnP networking. When a device is added to the network, the

UPnP discovery protocol allows that device to advertise its services to control points on the

network. Similarly, when a control point is added to the network, the UPnP discovery protocol

allows that control point to search for devices of interest on the network. The fundamental

exchange in both cases is a discovery message containing a few, essential specifics about

the device or one of its services, e.g., its type, universally unique identifier, a pointer to more

detailed information and optionally parameters that identify the current state of the device.

剩余195页未读，继续阅读

xinshujian

粉丝: 0
资源: 2

UPnP 2.0架构详解：设备发现与控制

UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf

UPnP详解以及代码

DLNA 2016和UPNP 2.0技术手册

Python库 | async_upnp_client-0.13.7.tar.gz

UPnP-av-AVArchitecture-v2.0

upnp 小型客户端源码

upnpclient:适用于Python 3的uPnP客户端库

harmonyos2-SSDP.UPnP.PCL:UPnP2.0的SSDP实现

光纤课程设计.doc

新媒体环境下汉语言文学教学优化策略.pdf

基于Python爬虫技术的海量电影数据分析系统源码

2022爱奇亿研发工程师笔试资料2022爱奇亿研发工程师笔试资料

师范院校汉语言文学专业民俗学课程的开设与教学模式.pdf

ISO 15118-20-2022中文翻译+英文原版.zip

高频注入全套方案 仿真模型生成代码 simulink matlab 效果优于某驱动 代码生成烧录到开发板，mdb，HFI 清单

GDAL-3.0.4-cp38-cp38-win32.whl

基于数字化驱动的公共管理模式创新研究.pdf

EXCEL进行CRC码计算演示

就业信息管理系统 JAVA高分毕业设计 Vue.JS+SpringBoot前后端分离项目.zip

公共管理硕士研究生知识转移影响因素分析.pdf

最新资源

高频注入全套方案仿真模型生成代码 simulink matlab 效果优于某驱动代码生成烧录到开发板，mdb，HFI 清单