Sponsored Link •
Committees, or working groups, of the UPnP Forum build upon the common framework by collaborating to define standard device types. The UPnP Device Architecture document details the protocols and conventions required of UPnP devices, and explains the basic pattern all UPnP devices follow in their operation:
Each UPnP phase has related network protocols. The TCP/IP protocol suite and HTTP provide the basic network connectivity for UPnP. Figure 2 shows the basic UPnP protocol stack.
A few aspects of UPnP require the sender to communicate with many recipients. For example, the UPnP device discovery mechanism allows devices to send presence announcements to all of the other devices on the network, letting them know of that device's availability. For that purpose, UPnP relies on a form of HTTP that is sent over multicast UDP, called HTTPMU. In some cases, response messages are sent directly back to the source using HTTP over unicast UDP, called HTTPU. The multicast-oriented protocol stack is shown in Figure 3.
A UPnP device may also contain other devices. That logical composition of devices gives the designer flexibility when determining how to implement the device. It also allows the embedded device to be discovered and used independently from the main container device. Figure 4 shows a detailed UML class diagram for a UPnP device.
Those familiar with interface-oriented object model systems, such as Microsoft COM or CORBA, can draw an analogy: a UPnP device is similar to an object, the services are like interfaces supported by the object, and the actions in a service are like functions in an interface.
Each UPnP service also has a service type Uniform Resource Identifier (URI) that
uniquely identifies the service. Standard service types are defined by a UPnP Forum
working committee. Every service also has a
serviceId URI that uniquely
identifies the service among all of a device's services. No two services may share
serviceId. The services that a device must implement are
determined by the device's type. The working committees of the UPnP Forum standardize
the set of services a device type must support.
Each service may also maintain variables that represent that service's current status. A service may have zero or more such variables. Each state variable has a name, a type, a default value, and a current value. It also has a set of allowed values to describe the range of permissible variable values. Any state variable can trigger events on state changes; when such events occur is determined by a service's implementer.
If a variable triggers an event to indicate a state, that variable is said to be evented. Every input argument to an action is associated with one of the service's state variables, termed the argument's related state variable. One of an action's arguments may be designated as the action's return value. The return value provides the result of the action to the caller. Figure 5 shows a UML class diagram for a UPnP service.
UPnP control points can subscribe to receive indications of state variable changes from a service. When a service detects a change to a state variable, that service notifies any registered control points of that change. For example, a service that renders audio tracks might keep a state variable of the URL of the current track being played. When the track changes, the service sends a state change notification with the new URL to all control points that have registered interest in receiving events from that service.
As the figure illustrates, a control point discovers devices, invokes actions on a device's services, and subscribes to event notifications. A device, on the other hand, responds to invoked actions, sends events when state variables change, and supports a Web page for administrative control (a presentation page in UPnP terminology).