UNDER THE UPNP HOOD
UPnP is a distributed, open networking architecture that leverages TCP/IP and the Web to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and everywhere in between. It comprises the following types of logical nodes:
User control point— A set of software modules that facilitates communication between itself and a number of controlled devices on a home network. Examples of devices that could function as a user control point include a standard PC, a digital set-top box, and high-speed broadband modems.
Controlled device— A set of software modules that facilitates communication with a user control point. The primary difference between a user control point and a controlled device is that the user control point is always the initiator of the communications session. Examples of devices that could function as a controlled device include VCRs, DVD players, security systems, and automated light controllers.
Bridge— A set of software modules that allows legacy devices to communicate with native UPnP devices.
Bridged device— A device that cannot participate in UPnP at the native protocol level, either because the device does not have sufficient hardware resources or because the underlying media is unsuitable to run TCP and HTTP protocols. Examples of devices that could be bridged devices are power line-controlled A/V equipment, light switches, thermostats, wristwatches, and inexpensive toys.
In order to achieve interoperation among these devices on a home network, UPnP is based around five key mechanisms. Understanding these mechanisms is the key to gaining a glimpse of the potential of UPnP technologies. The mechanisms are
Device model
Addressing
Discovery
Schema
Rehydrator
The next sections of this chapter present an overview of these UPnP home networking mechanisms and looks at how they work together in practice.
Device Model
The UPnP device model was designed to be general and flexible. It comprises a number of elements for a controlled device or bridge that is emulating native controlled devices. Figure 13.3 shows the main elements.
Every device includes:
Optionally one or more home networking services— A service is defined in UPnP terms as a controllable entity. Every running instance of a service includes:
Service state table (SST)—A table of data that consists of rows of information on the current, electrical, mechanical, and logical state of a specific service. The SST for a set-top box could represent the tuner frequency, video decoding format, and current channel selection. The SST for a clock would likely represent the current time.
Service command set—A set of commands that can be invoked by a UPnP service.
Event subscription server—An event is an unsolicited message generated by a controlled device and delivered to one or more user control points.
Figure 13.3. UPnP device model
Events are used to maintain a consistent view of the state of service across all interested user control points. A software module called an event subscription server that runs in a controlled device or bridge is used by UPnP to respond to requests from user control points.
Control server—This server accepts incoming commands and passes these commands to the service's native command processing logic and waits for command completion. When the command is completed successfully, the SST is updated, an event is generated, and a successful response is returned to the user control point. In the event of an illegal command or unsuccessful command, no changes are made to the SST and a failure response is returned.
Uniform resource locators—They identify the control and event subscription server.
One or more device types— In relation to the device model, a device represents a container for home networking services. From the perspective of a home networking user, a device generally models a physical entity such as a game console, but can also represent a logical entity. A digital set-top box emulating the traditional functions of a PC would be an example of a logical device. Devices can contain other devices. An example would be a TV/VCR packaged into a single physical unit. A device may also be a logical container of other devices. The top-most device in a hierarchy of nested devices is called the root device. A device with no nested devices is always a root device. All devices, including root devices, belong to one or more device types. A device type is a relatively high level classification of devices with common functionality. An example of a device type is a "DVD player." Similar to the DNS system on the Internet, UPnP also supports human-friendly names for devices connected to a home network. A typical friendly name for a device will contain the manufacturer and model information of the UPnP device.
Optionally a presentation server— A presentation server is a Web server that runs in a controlled device that responds to HTTP-based requests or presentation URLs and returns a graphical Web interface.
A globally unique identifier called the Unique Device Name (UDN)— The UDN is a globally unique address that is used to unambiguously identify a device on a home network. It is a permanent address, even across power cycles and physical location changes.
Description document and server— A description document is a structured unit of data that is used by a user control Point or UPnP bridge to learn the capabilities of a controlled device. Description documents are retrieved from the description server on a UPnP-controlled device. A description server is a standard HTTP server that responds to description document requests from various devices on the home network.
There is one description document for every root device that describes the root device and all nonroot devices. Description documents adhere to the grammar of the XML standard and to the UPnP Architecture Reference. It is also important to note that devices that are described as being a root device also include the description document and description server for all devices under and including itself.
Addressing
UPnP is built on top of the HTTP protocol and leverages the address format of the Web—Uniform Resource Locators (URLs). Every item of information on the Internet has a unique address called a URL. An example of a URL is as follows: http://www.set-tops.com.
This particular URL addresses the home page at set-tops.com. All URLs have two main parts: the protocol identifier and the resource name. In this example, HTTP is the protocol identifier and www.set-tops.com is the resource name. You will notice a colon (":") is used to separate the two components. In the context of a UPnP-based home network, the resource name part of the URL can represent a file or simply an identifier of a local software module. The various types of addresses that are used by UPnP-based home networks are described in Table 13.1.
| URL | Function |
|---|---|
| Description URL | Points to the description server and document path on a root device. This URL is returned by the description server as part of the discovery process. |
| Presentation URL | Points to a presentation (Web) server on a controlled device. There is one presentation URL per device, including root devices. This URL can be entered into the address bar of a Web browser to navigate to the root web page of a device. This URL is returned in the description document. |
| Control URL | Points to the control server implementing a service on a controlled device. There is one control URL per instance of a service. This URL is returned in the description document. |
| Event Subscription URL | Points to an event subscription server on a controlled device. This URL is returned in the description document. |
| Event Sink URL | Points to an event sink (an HTTP server) on a user control point. |
Discovery
Discovery is the process by which UPnP applications and services find each other. The first part of the discovery process takes place when a device plugs into the home network. It sends out a small multicast packet to other appliances on the network. The multicast packet essentially says, "I am here, I am a DVD player (for example), and you can reach me at this address or URL." Once the device has established itself on the home network, it is then capable of discovering new services. The main elements of a discovery system include:
Discovery server— A software module on a controlled device or bridge that responds to queries.
Discovery client— A software module that runs in a user control point that initiates queries.
Universal Plug and Play uses the SSDP protocol for the discovery of devices on IP networks. SSDP is based on profiles. A single identifier specifies a profile that defines a contract between the client and service. By identifying itself with the profile, the service advertises compliance with the associated contract. Using a single identifier makes it possible to implement an extremely simple discovery system. Clients send out a UDP multicast packet containing the identifier of the desired service on some standard channel. Services listen on the standard channel, read the request, see whether they provide the service, and respond if so. Discovery questions can be very specific, such as "Is there a printer on the home network?" Furthermore, UPnP-based discovery systems can also restrict a discovery search by IP address. For instance, a requesting device can send out a message that only integrated TV's can answer.
Directories provide a mechanism to allow discovery to scale—to the entire Internet if needed. When present, a directory will read all incoming service requests and respond to them itself. This requires that all services register with the directory so that the directory is able to properly answer on their behalf. The directory is also responsible for communicating with other directories in order to determine whether the service is available within the local home network and potentially the Internet.
To simplify the discovery protocol, directories are treated as proxies. A proxy is a service that accepts requests and takes responsibility for finding the proper response. When a client comes online, it will perform discovery for the proxy. If the proxy is present, then the client will send all future discovery requests to the proxy. If the proxy isn't present, then the client will send all discovery requests to the reserved discovery multicast channel. Regardless of the presence of a proxy, the client's request format and procedures will always be the same. The only difference will be the address to which the client sends its requests.
For services, the difference between a proxied and unproxied network is their need to answer discovery requests. On a proxied network, services need do nothing once they have registered with the proxy. On an unproxied network, they answer discovery requests directly. SSDP uses UDP- and TCP-based HTTP to provide for service discovery. SSDP also will provide support for proxies. These proxies, which are really just fronts for directories, redirect discovery requests to themselves. It is the proxy's job to collect announce requests (see next section) in order to determine what services are available as well as to communicate with other proxies in order to provide for scalable service discovery.
Schema
The discovery process returns only the basic information needed to connect to a device. Once a service has discovered its peers, the service often needs to find out more information in order to work best with them. The description process returns a schema providing descriptive data about the service.
A schema is a structured data definition that defines a set of structured values that provide descriptive information about a service. Universal Plug and Play will use eXtensible Markup Language (XML) for schema, because XML's self-describing structured data format provides the level of expressiveness and extensibility needed by a universal schema and data format.
Rehydrator
Any service that is exposed by a UPnP-based control device or bridge can be remotely controlled and managed. Controlling these services normally involves the exchange of messages between a user control point and the particular device. This exchange of messages happens according to a specific service control protocol (SCP). In-home appliances use this protocol to invoke commands and return results.
A rehydrator is best described as a software module that exposes a suitable API to home-networked applications. The primary job of the rehydrator is to map between API calls and the SCP sequence that invokes the initial command. The success of this operation is dependent on the presence of a service control protocol declaration (SCPD).