Development Notes

These may be of some interest.

Device state management

It should be possible to add and remove devices dynamically.

For example, an application may contain a MODBUS controller which communicates with various slaves to switch lights, garden pumps, etc. We’ve also decided to create a UPnP device object for each MODBUS slave.

If we add a new slave to the network, then our application creates a new UPnP device object and passes it to e.g. ‘UPnP::addDevice()’, which does this:

  • Add the device to the stack

  • Queue a set of ‘ssdp:alive’ announcements

  • Notify the application via callback that the device has been added

If a slave is to be taken out of the network:

  • Remove the device from the stack so it won’t respond to any new requests

  • Queue a set of ‘ssdp:byebye’ announcements

  • When the final announcement has been sent, notify the application via callback that the device has been removed

When the application gets a ‘remove’ notification it can safely destroy the object, if appropriate, as UPnP has finished using it.

Device tree

Add parent device to embedded devices so we can track back up the tree. Still not clear on whether a device needs to know about its direct parent, or whether a reference to the root device is adequate. A service certainly needs to know about its parent. So we need both root and parent. Root can be obtained by traversing back up the tree.

Icons

Add IconList support

Control Points

This involves sending search requests and responding to advertisements. Requesting descriptions also parsing XML. Using a SAX parser (as listed above) would allow template classes to be populated and passed to an application callback for handling. It would be the application’s responsibility to decide what information to keep and how to manage it.

UPnP version

Decide how to handle versioning. We should support previous versions but selectively enforce version 1.0, 1.1 or 2.0 as required. The version must be consistent throughout a device stack so we should add this as a configurable value for root devices. This then gets propagated into embedded object descriptions as well. We can have multiple root devices at different versions.

URL handling

Responses from VR900 are illuminating. Gateway is on port 1900, media server on 8200. There doesn’t seem to be any technical reason why multiple root devices can share the same port, but using separate ports does mean we can use separate HttpServer instances.

It would not make much sense for a URL to be somewhere completely different, but it doesn’t appear to be prohibited by the V1.0 spec. V2, however, deprecates URLBase and mandates that URLs are all relative to the SSDP response location (where the description file is served from).

Demonstration of discovery

Write a sample for Host which performs an ssdp:all discovery and writes all the description files into a directory tree structure.

Issue multicast search, register callback to receive responses For each response, store in a table (Vector)

If not already in table, queue an HTTP request for the description file
On receipt, write out the description file into a directory:

<ip>/<port>/<path>/

Queue an HTTP request for the presentation page

Write to same location

Components required:

Item table. Implement using Vector. Contains:

IP Address Port number

HTTP request queue. Only service one fetch at a time.