Network Service Discovery API Support in Opera
- What is the Network Service Discovery API?
- Download a build
- What does this build do?
- How do I use it?
- Can I see any demos?
- Are these builds production-ready?
- Anything else to be aware of?
- If you have problems
- What’s next?
According to Nielsen, as of 2009 nearly 60% people in the US used their TV and internet simultaneously for an average of 2.5 hours per person per month. That’s around 128 million people and just over 19 billion minutes of simultaneous viewing per month! It’s not surprising, then, that we’ve seen a surge of interest in multi-screen development recently. As part of this, we’ve submitted a draft specification to the W3C entitled Network Service Discovery API which aims to ease discovering and sharing data between devices.
What is the Network Service Discovery API?
Download a build
We have implemented this API in an Opera Labs build for desktop, available for you to download and experiment with. You can download the build most suited for your platform here:
- Opera desktop for Windows: 32 bit, 64 bit
- Opera desktop for Mac
- Opera desktop for Linux: i386 (deb), amd64 (deb), i386 (RPM), x86_64 (RPM), i386 (.xz), x86_64 (.xz)
- Opera desktop for FreeBSD: i386, amd64
Note: For this API to work, you must enable two features in this build:
- Go to
opera:config-> Enable Service Discovery API, check the box and click Save.
- Go to
opera:config-> Allow Cross Network Navigation, check the box and click Save.
What does this build do?
This build is based on the Network Service Discovery API specification snapshot dated 4th October 2012 with the following caveats:
- The desktop builds support UPnP Service Discovery only at this early stage. We plan to also support Zeroconf discovery in our API.
- We have not yet implemented UPnP Event Subscription functionality.
- We are not currently shipping a user interface for this so you will need to set the
opera:config#UserPrefs|EnableServiceDiscoveryAPIflag to enable this API.
<?xml version="1.0" encoding="utf-8"?>
The most common use case at this stage is to search for media files on a server and play them in a renderer on a separate client. The API can even be used to change the volume on a UPnP-enabled TV. There are a few more use case suggestions in the spec and we’re looking forward to seeing what innovative services you can come up with.
How do I use it?
It’s probably best to look at a basic example by breaking it down into a few simple steps:
- Call the
navigator.getNetworkServices()method, passing it a list of well-known service types to look for.
- If successful, specify a callback function to execute. Its argument is an array of found services.
- Commands are sent to your chosen service’s URL usually using an XMLHttpRequest (but the API also allows you to theoretically connect devices via Web Sockets).
- If necessary, the service’s response can be parsed and then acted upon by your web application.
To simplify the process, we have also created the Plug.Play library which acts as a UPnP service layer abstraction on top of
navigator.getNetworkServices(). The library’s home page includes a detailed breakdown of the steps mentioned briefly above — how to use
navigator.getNetworkServices() and how to then, optionally, use the library to invoke UPnP actions and process responses.
Can I see any demos?
We’ve prepared a couple of simple demos to demonstrate the discovery concept. The first is a media player demo which acts as a middle-man between media servers and renderers The second is a web-based UPnP inspector so you can monitor and edit messages to and from UPnP devices. Of course, to test these out you need UPnP services available on your network. Wikipedia has an extensive list of UPnP media servers and clients, both hardware and software.
Are these builds production-ready?
No. The main issue is that there is no UI or privacy mechanism at this point – in other words, web pages have full access to all UPnP services on your local network and a call to getNetworkServices will return all services that match the requested service type. Because of this, the Service Discovery API needs to be enabled manually in opera:config in the builds provided on this page, as mentioned earlier.
Ultimately, this API will ship with an opt-in interface to allow users to authorize a web page to connect with one or more services that the page has requested. We are currently hard at work imagining this user interface. When we have a good user experience story to tell for this API we will provide updates on this blog.
Anything else to be aware of?
A couple of things:
getNetworkServicesmethod will look for services for up to three seconds. The time limit is because of the current lack of UI but it can be adjusted in opera:config -> Service Discovery Time Ms.
- There is a bug in VirtualBox on Windows that causes all multicast communication to be blocked, including but not limited to UPnP discovery. If you have VirtualBox installed on your system, disable the “VirtualBox Host-Only Ethernet Adapter” network interface and restart Opera (or, in rare cases, the whole system).
If you have problems
If you have trouble getting the demos or your own code to work, there are number of things that could be the cause. Here are some steps to take to fix the problem.
- The first thing to check is that you have enabled the two essential options in
opera:config. See the download section for details.
- If that doesn’t work, it could be an issue with the UPnP device you’re using. We’ve noticed differences in UPnP support even within a single product line of TVs, for example. Please try with another UPnP device if possible, or test using a UPnP server and renderer installed on your own PC first.
- Another cause could be file formats. UPnP renderers are restricted by the formats they can decode and play so trying media files in various formats may help.
- If the problem still persists then please leave a comment at the bottom of this article or a message in the Dev.Opera forums.
We are currently discussing and iterating on the current Network Service Discovery specification in the W3C Device APIs Working Group. If you would like to contribute to development of this specification, you should join the public mailing list.
One future improvement we are considering is to enable web pages to register themselves as services and advertise themselves on the local network. This would mean they could communicate with other devices in a network peer-to-peer, even between web pages on different devices!
As this is the first implementation of an early specification, any developer feedback is extremely valuable. We’d be grateful if you could let us know in the comments section below about your experiences with these builds, as well as ideas you may have for other use cases and improvements we could make. One improvement that has lots of potential is support for Zeroconf, meaning web pages could talk to iTunes, AirPlay devices, etc.
Multi-screen capability is a fast-moving technology so watch this space!