UPnP uses
SSDP to announce the Device and each of its nested Services. Since each
SSDP message can announce only a single type, announcing a Device required multiple messages, so many that we had to come up with a formula to express it: 3 + 2
d +
k, where
d was the number of nested Devices, and
k was the number of nested Services. Besides the obvious burden on the network, this introduced a mismatch between the logical model (single Device coming or going on the network) and the network implementation (multiple announcement or departure messages). It was then up to the Control Point (a
UPnP term, think "client") to make up the difference; if it saw one of the 3 + 2
d +
k announcements, should it infer that the entire Device was available? Or should it discard any announcement from an incomplete suite? (And how could it tell if the suite was complete or not?) Should it behave differently for departure messages?
UPnP also envisioned that Services would be stand-alone functional control units, and that it would make sense for a Control Point to communicate with a Service sans knowledge of the Device in which the Service was nested. A scenario of the day was a volume Service to which a generic Control Point might send a 'mute' action to quiet the room to answer a telephone call. Of course, that meant that the volume of the telephone couldn't be controlled by a 'volume' Service, and the volume of the smoke alarm couldn't be controlled by a 'volume' Service, etc.
UPnP Forum working committees weren't confused on this point,
defining Services that are used in context, effectively requiring a Control Point to recognize (and search for) the Device first.
WS-Discovery avoids the first issue by allowing richer content within a single message (within UDP size limitations), and the
Devices Profile avoids both issues by including only Device (and
not Hosted Service) information in
WS-Discovery messages.
Posted
Nov 11 2004, 02:46 PM
by
jeffrey-schlimmer