UPnP Device Architecture 1.0 整合说明文档

需积分: 10 174 浏览量更新于2024-07-25 收藏 508KB PDF 举报

"CyberLink for Java 是一个与DLNA相关的技术文档，主要涉及UPnP（通用即插即用）设备架构1.0版本的详细说明。这份文档整合了包括AutoIP、SSDP、HTTPU/MU、FXPP和GENA在内的多个单独规范，并对UPnP Vendor Implementation Guide中的澄清内容进行了编辑整理。它不引入新的技术要求，而是对现有规范进行编辑上的澄清。文档由Allegro Software Development Corporation、Conexant Systems、Intel Corporation、Microsoft Corporation、Motorola、Nokia Corporation、Philips Electronics、Pioneer和Sony Electronics等多家公司贡献者共同编写，并受UPnP™ Forum的版权保护。" 本文档主要知识点如下： 1. **UPnP技术**：UPnP（通用即插即用）是一种网络协议，旨在简化设备之间的连接和通信，使得设备无需用户手动配置即可在网络中发现和交互。UPnP技术广泛应用于智能家居、多媒体设备和移动设备，提供了一种标准化的方式来实现设备的互操作性。 2. **UPnP论坛**：UPnP™ Forum是一个行业协会，由全球多家科技公司组成，致力于推动UPnP技术的发展和标准制定。该论坛的成员包括文档提及的Allegro Software、Conexant Systems等企业，他们共同贡献和维护UPnP的相关规范。 3. **文档结构**：文档包含引言、目标读者、必需与推荐的区别、缩写词、参考资源等内容。这部分旨在帮助读者了解文档的目的、适用人群以及如何找到更多的参考资料。 4. **网络地址处理**：文档详细介绍了在网络环境中如何处理设备的地址。例如，如何决定是否使用Auto-IP来自动获取IP地址，选择地址的策略，以及如何测试地址的有效性。这些内容对于设备在网络中的正常运行至关重要。 5. **协议规范**：文档整合了AutoIP、SSDP（简单服务发现协议）、HTTPU/MU（HTTP用户代理/媒体服务器）、FXPP（快速启动和播放协议）以及GENA（一般事件通知架构）等规范，这些都是UPnP设备架构的核心部分，用于设备的发现、控制和数据传输。 6. **编辑性澄清**：文档强调它仅是对现有规范的编辑澄清，意味着文档中没有新增的技术要求，而是对已有的规范进行了明确和解释，以帮助开发者和制造商更好地理解和实现UPnP技术。 7. **版权信息**：所有内容受2008年UPnP™ Forum贡献成员的版权保护，并提供了获取更多信息的链接（http://www.upnp.org/info/cpyright.asp），提醒读者尊重知识产权。 "CyberLink for Java"说明文档是深入理解UPnP设备架构和实施DLNA服务的重要资源，对于开发和部署支持UPnP的Java应用程序的工程师来说非常有价值。通过学习这份文档，开发者可以掌握如何在各种设备之间实现无缝的媒体共享和控制。

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, and a pointer to more detailed information.

When a device is removed from the network, it should, if possible, multicast a number of discovery messages revoking its earlier

announcements, effectively declaring that its embedded devices and services will no longer be available. When the IP address of

a device is changed, it should revoke any earlier announcements and advertise using the new IP address.

For devices and control points that have multiple network interfaces, UPnP advertisements and searches should be sent on all

network interfaces enabled for UPnP networking. Each advertisement or search must specify an address in the LOCATION header

that is reachable on that interface

To limit network congestion, the time-to-live (TTL) of each IP packet for each multicast message should default to 4 and should

be configurable. When the TTL is greater than 1, it is possible for multicast messages to traverse multiple routers; therefore

control points and devices using non-AutoIP addresses must send an IGMP Join message so that routers will forward multicast

messages to them (this is not necessary when using an Auto-IP address, since packets with Auto-IP addresses will not be

forwarded by routers).

Discovery plays an important role in the interoperability of devices and control points using different versions of UPnP networking.

The UPnP Device Architecture (defined herein) is versioned with both a major and a minor version, usually written as

major.minor, where both major and minor are integers (for example, version 2.10 [two dot ten] is newer than version 2.2 [two

dot two]). Advances in minor versions must be a compatible superset of earlier minor versions of the same major version.

Advances in major version are not required to be supersets of earlier versions and are not guaranteed to be backward compatible.

Version information is communicated in discovery and description messages. In the former, each discovery message includes the

version of UPnP networking that the device supports (in the SERVER header); the version of device and service types supported is

also included in relevant discovery messages. As a backup, the latter also includes the same information. This section explains

the format of version information in discovery messages and specific requirements on discovery messages to maintain

compatibility with advances in minor versions.

The remainder of this section explains the UPnP discovery protocol known as SSDP (Simple Service Discovery Protocol) in detail,

enumerating how devices advertise and revoke their advertisements as well as how control points search and devices respond.

1.1 Discovery: Advertisement

When a device is added to the network, the device advertises its services to control points. It does this by multicasting discovery

messages to a standard address and port (239.255.255.250:1900). Control points listen to this port to detect when new

capabilities are available on the network. To advertise the full extent of its capabilities, a device multicasts a number of

discovery messages corresponding to each of its embedded devices and services. Each message contains information specific to

the embedded device (or service) as well as information about its enclosing device. Messages should include duration until the

advertisements expire; if the device remains available, the advertisements should be re-sent (with new duration). If the device

becomes unavailable, the device should explicitly cancel its advertisements, but if the device is unable to do this, the

advertisements will expire on their own.

1.1.1 Discovery: Advertisement protocols and standards

To send (and receive) advertisements, devices (and control points) use the following subset of the overall UPnP protocol stack.

(The overall UPnP protocol stack is listed at the beginning of this document.)

UPnP

vendor [purple

]

UPnP

Forum [red

]

UPnP

Device Architecture [green]

SSDP

[blue]

HTTPMU (multicast) [black]

UDP [black]

IP [black]

At the highest layer, discovery messages contain vendor-specific information, e.g., URL for the device description and device

identifier. Moving down the stack, vendor content is supplemented by information from a UPnP Forum working committee, e.g.,

device type. Messages from the layers above are hosted in UPnP-specific protocols, defined in this document. In turn, the above

messages are delivered via a multicast variant of HTTP extended using additional methods and headers. The HTTP messages are

delivered via UDP over IP. For reference, colors in [square brackets] above indicate which protocol defines specific headers and

values in discovery messages listed below.

1.1.2 Discovery: Advertisement: Device available -- NOTIFY with ssdp:alive

When a device is added to the network, it multicasts discovery messages to advertise its root device, any embedded devices, and

any services. Each discovery message contains four major components:

1. a potential search target (e.g., device type), sent in an NT (Notification Type) header,

2. a composite identifier for the advertisement, sent in a USN (Unique Service Name) header,

3. a URL for more information about the device (or enclosing device in the case of a service), sent in a LOCATION header,

and

4. a duration for which the advertisement is valid, sent in a CACHE-CONTROL header.

To advertise its capabilities, a device multicasts a number of discovery messages. Specifically, a root device must multicast:

• Three discovery messages for the root device.

NT USN

upnp:rootdevice uuid:device-UUID::upnp:rootdevice

uuid:device-UUID

(for root device UUID)

urn:schemas-upnp-org:device:deviceType:v

urn:domain-name:device

:deviceType:v

uuid:device-UUID::urn:schemas-upnp-org

:device:deviceType:v

(of root

device) or uuid:device-UUID::urn:domain-name:device

:deviceType:v

剩余79页未读，继续阅读

lyfadd85

粉丝: 5
资源: 7

UPnP Device Architecture 1.0 整合说明文档

cyberlink资料整理1

基于UPNP的CyberLink库详细说明

开源好用的DLNA库推荐下

有什么AI动漫视频编辑软件

pc端有什么播放器软件支持播放杜比视界视频

手机和电脑处理图片+音频+视频+电子书的软件+各推荐15个

pc端什么软件支持播放杜比视界视频

cwp文件如何转化成mp4文件

2进制3位数过去现在将来输赢公式代码.txt

福州大学在广东2021-2024各专业最低录取分数及位次表.pdf

最新资源