The MediaScape project is looking at what’s needed to enable a future where media can be pushed, pulled and shared across devices of all kinds. An important question to be answered is how devices announce and find each other on the network and describe what they’re capable of to others. We started by investigating existing discovery protocols that provide these features.
Our colleagues Libby Miller and Chris Needham already completed a literature review of existing discovery mechanisms. The MediaScape project is focused on web technologies so we looked to the W3C to see what discovery protocols it is investigating. The W3C published a working draft specification for service discovery that mentions two existing standards, DNS-based service discovery (DNS-SD) and Simple Service Discovery Protocol (SSDP). Although there is muchdiscussion of how these discovery protocols should be exposed in browsers, the protocols themselves are widely used so it made sense to pick these two existing standards to investigate in more detail. R&D has previously explored discovery for the Universal Control API and chose DNS-SD as the discovery mechanism. The UC Overview Whitepaper gives a detailed comparison of these protocols ("6.2 Discovery", p. 19).
To understand the capabilities of both protocols and the ease of working with them we built a simple technical prototype that could list the advertised devices and services on a local network.
For this prototype we only consider discovery of devices that are all on the same local network. We’ll be looking at other types of discovery in future work.
Our use case
As a simple use case, we’re interested in a device advertising on a local network that it can play media. We then want to allow clients to connect over the network to control the device. Our software stack uses Node.js and so we evaluated libraries in Node for mDNS and SSDP.
Do these protocols and libraries allow us to do that?
DNS-based service discovery with multicast DNS
DNS-SD works by creating DNS records that advertise types of services. The DNS records can be either within a network (using multicast DNS, mDNS) or visible more widely. We’re interested in the mDNS use case as it allows devices to advertise themselves on a local network with zero configuration (also known as “zeroconf”).
From an service advertisement point of view, DNS-SD/mDNS is well supported with Apple offering libraries for Mac OS X and Windows. Linux has the Avahi open source library. The Node.js library we used relies on those libraries being available at installation time in order to run.
For service discovery, device support is mixed. There’s no native support on Windows or Android but is possible using additional libraries.
No central server is required to manage discovery. Service types can be determined by the advertiser, although there is a central register of types.
The protocol has a concept of subtypes, which allow specialisation of service types. For example, a printer with a web interface might advertise a service type of _http._tcp with the subtype of _printer. Unfortunately, we found that in Apple Mac OS X at least, the subtype wasn’t reported although searching and filtering for these services using subtypes worked as expected. Subtypes seem like an ad-hoc solution-left to the protocol implementor to define-with no rigidly specified URIs to define subtypes completely.
Since DNS-SD is based on DNS, it can be used for discovery of services across the Internet, not just on the local network.
Simple Service Discovery Protocol
SSDP uses part of HTTP 1.1 over UDP. The protocol supports the announcement of service state as they become available and unavailable. It also allows clients to query the network to ask what services are available.
We found lots of services on our home networks advertising via SSDP. These tended to be media devices because SSDP is defined as part of the UPnP standard.
In our office trials, we tried to use a couple of open source media servers that had SSDP support. We found that XBMC doesn’t respond to M*SEARCH queries which means that new clients cannot find its services when they join the network.
The SSDP library we found uses Node’s UDP socket support directly for both service advertisement and discovery. It doesn’t rely on an external library for its implementation. This bodes well for cross-platform server installations.
SSDP recommends using unique IDs for service names and doesn’t maintain a registry of service types. Service types are identified using a URI scheme. This allows a client to search for very specific service types only.
SSDP assumes that client and service communicate via HTTPU.
The service discovery tool is a really simple app, built with Node.js that uses the node-ssdp and the node_mdns libraries. When a new service is discovered, the information is pushed via Server Sent Events through to a simple web-based interface.
Video of the app showing a list of DNS-SD and SSDP-compatible devices on a typical home network. Green rows are active services, red rows show services that have announced their departure from the network
Evaluating these protocols has given us a better understanding of the capabilities of the discovery mechanisms available to us today. For our specific use case, we'll be using DNS-SD since:
we require a general, self-contained protocol that allows the expression of any service type. DNS-SD offers this but SSDP is part of the UPnP specification which ties it heavily to UPnP services;
DNS-SD theoretically offers service discovery across the internet in addition to the local network.
In parallel to this, Andrew Wood and Lianne Kerlin have been exploring the user experience of discovery and we'll publish a blog post of our findings soon. We'll combine these two explorations to create a prototype that allows the remote control of a radio device from a web page, using DNS-SD to advertise devices that are available to be controlled remotely.