Seite 1 von 1
Behavior of Control Point
Verfasst: 15. Jan 2008 16:11
we have implemented both Components Service and Control Point. We can successfully validate our "Device with Service". But when we use the Intel Device Validator for the Control Point the section "Discovery/notification Test Suite" and there at the point "Discovery", it hangs itself up after the Test "Service type, bad Version" has successfully passed.
Is it correct, that the Control Point sends Notifies and answers M-Searchs in order to be discoverable in the network?
Our Device with the Control Point offers no services and the Device Description for Control Point contains no "servicesList"-Tags and no "services" attributes. Is that the problem, why the Intel Validator brakes down?
But if this comes true, how can we advertising the Control-Point, which should not have services?
Re: Behavior of Control Point
Verfasst: 15. Jan 2008 17:12
First of all, a couple of comments regarding roles of devices and control points, that I believe will help clarify the problem:
Control points are clients, and the Devices are the servers providing/offering a given functionality. That's why everything that is a upnp device must publish an xml with the description of the services it offers.
Control points (say, "pure control points") don't need to publish that, since their role is to be clients. A control point (e.g., a device looking to use a projector) usually multicasts a search message (ssdp:discover), and handles the notifications from the devices responding the requests.
What usually happens (and I believe that's the problem here) is that it is always easier to implement a control point as an extension of a upnp device (because of the notifications and discovery). BUT, you should test your device with the upnp validator, not the control point if you're implementing it as a "pure" control point. If you look carefully the validator tool, all the tests are for the devices...
Finally, if you did implement a device with a control point, be sure that the functionality "as device" is correct (together with the xml description), and be sure you handle internally in which state you're device is operating so you don't confuse the roles of device and control point.
Re: Behavior of Control Point
Verfasst: 15. Jan 2008 17:25
...And I forgot to answer this:
"Is it correct, that the Control Point sends Notifies and answers M-Searchs in order to be discoverable in the network?"
The control point doesn't have to be discoverable, it must be able to discover the devices. ALL OF THEM. The devices are the ones that should be discoverable. The control point may also be able to retrieve the device description of any upnp device, but have the "intelligence" to control at least one kind of device (-the one you have implemented-)
If you implemented a device that also has a control point, well, then of course it must answer M-Searches but not because it is a control point, but because it is a device. Be careful with the roles...