How MHP Applications Are Loaded

We’ve already seen how the receiver knows about available applications, and how it knows which ones can be started and which ones are to be killed. Now, we will look at how we can actually load the files that make up an application. Each DVB-J application will consist of a set of class files and possibly some data files, while each DVB-HTML application will consist of a set of HTML files (and possibly ECMAScript and CSS files) and associated data files. In both cases, all of these files can be carried to the receiver in a number of ways.

Loading Java classes is slightly more complex than loading data files, because the middleware has to handle issues such as searching the classpath correctly and handling the different transport protocols that application developers can use. In the rest of this tutorial, we will concentrate on DVB-J applications, although the same techniques will apply ot DVB-HTML applications as well. We will see how a receiver knows where to find the classes for an application, and how an application can influence this when it is running.

Transport protocols

We have already mentioned that the AIT entry for every application will include a class path and a base directory. This tells the receiver where it should look for classes and data files, but this on its own does not give us enough information to resolve this completely. The class path and base directory will tell the receiver what directories it should search for application files, but not where to find those directories. In an MHP or OCAP receiver, there are three ways of getting data to the receiver, and so we need to tell it which method is being used for a particular application.

• Most MHP applications today will load their files from a DSM-CC object carousel that is carried as part of the MPEG transport stream. From a Java perspective, we can treat this as just another filesystem, and load classes and data files using the normal file operations. This is a big advantage, even though it can take a long time to load files from an object carousel. The other advantage of object carousels is that they are ubiquitous: every receiver will support them, there are many tools that will produce them, and generally they’re a pretty well-understood way of getting data to a digital TV receiver that does not rely on any other equipment.
• MHP theoretically supports loading applications from a multicast IP connection that is carried in a DSM-CC multi-protocol encapsulation stream. We say ‘theoretically’ because the MHP specification deliberately does not define some elements that are important to make this work interoperably, and so this is not likely to be very useful in practice.
• Finally, MHP 1.1.x adds support for loading classes and data files from the return channel using HTTP and mapping this on to the normal file operations. Obviously this is only applicable to the Interactive Broadcast and Internet Access profiles, where the receiver will have a return channel. Loading applications over the return channel potentially means faster startup times (if the receiver has a fast enough return channel) and more bandwidth available for other purposes, but it does rely on a broadband return channel to be truly effective. Since few receivers have this at the moment, and even fewer (i.e. none) support MHP 1.1, application loading over the return channel is not widely used at the moment.

These may all be used at the same time, and a service may include applications loaded via any or all of these protocols. This complicates things for the middleware, and application developers need some way

The transport protocol descriptor

To tell the receiver which protocol we use to load an application, we add a transport protocol descriptor to the Application Information Table. This can appear in either the common descriptor loop or in the descriptor loop for a particular application, but each application must be in the scope of at least one transport protocol descriptor. For applications that are in the scope of two descriptors, e.g. one in the common descriptor loop and one in the application descriptor loop, then the descriptor in the application descriptor loop will take precedence.

The transport protocol descriptor has the syntax shown below:

There are two fields here that are of interest to us. The first of these is the protocol_id field. This tells the receiver which protocol is used for carrying the files belonging to the application. A value of 0x0001 indicates that files for that application are carried in an object carousel, while a value of 0x0002 indicates that the files are carried i a multicast IP stream using DSM-CC multi-protocol encapsulation. A value of 0x0003 tells the receiver that the application should be loaded over the return channel, but this is only valid for MHP 1.1.x systems.

The second field is the selector. This is a structure that contains protocol-dependent information telling the receiver where to find the files. For an object carousel, the selector has the following structure:

The remote_connection field indicates whether the stream containing the object carousel is part of the current service. If it is not, then the selector will contain the original network ID, transport stream ID and service ID of the service containing the carousel. No matter which service contains the object carousel, the selector will also include the component tag for the stream carrying the carousel. This lets the receiver choose the correct stream in those cases where a service contains more than one carousel.

For an IP multicast stream, the selector has the following structure:

Several of these fields are identical to those found in the selector for object carousel transport. In addition to these, the alignment_indicator field tells the receiver whether data in the IP datagrams is aligned in 1-byte or 4-byte groups with respect to the transport stream packets that carries it. Finally, this selector defines a set of URLs. Unfortunately, the MHP specification deliberately does not define which URL formats should be supported, except to say that it must meet the syntax laid down in RFC 2396 and that hosts should be described by their IP addresses rather than by names. Without this information, and clarification on how these URLs should be used by the receiver, it is not possible to use this transport protocol in an interoperable way.

For applications loaded over the return channel, the selector looks like this:

This defines a number of URLs that should be treated as a search path for class files. For efficiency reasons, URLs are split into a common ‘base’ part and a set of extensions that are added on to this base to describe different parts of the filesystem. For instance, a selector could define the URL base http://www.cnn.com/ and the extensions common/, apps/Ticker/, and apps/launcher/Launcher.zip. These extensions would get added to the URL base to give the following full URLs:

• http://www.cnn.com/common/
• http://www.cnn.com/apps/Ticker/
• http://www.cnn.com/apps/launcher/Launcher.zip

The HTTP filesystem

Now that we have a set of URLs, what do we do with them? How do they interact with the class path and with request for loading classes or other files?

In effect, these URLs describe the filesystem for that application. Taken together, these URLs describe the ‘root’ of that filesystem, and when the middleware needs to load a file for that application, it will search each of those URLs for that file. Lets consider a simple case first. If the application tries to load the file background.jpg, then the middleware will try to find that file at the following URLs:

1. http://www.cnn.com/common/background.jpg
2. http://www.cnn.com/apps/Ticker/background.jpg
3. http://www.cnn.com/apps/launcher/Launcher.zip

In the last case, the middleware would load the ZIP file and check to see whether background.jpg was contained in that ZIP file. If we were trying to load the file data/headlines.txt the middleware would try to find that file at the following URLs:

1. http://www.cnn.com/common/data/headlines.txt
2. http://www.cnn.com/apps/Ticker/data/headlines.txt
3. http://www.cnn.com/apps/launcher/Launcher.zip

Again, in the last case the middleware would search inside the ZIP file.

Loading classes is slightly more complex, because we also have the classpath to worry about. In this case, the normal classpath search order will be followed (i.e. first look in the application base directory, then first entry in the classpath extension, then the second, etc.). The only difference is that instead of searching a single directory for each classpath entry, the middleware will search every URL listed in the transport protocol descriptor. To give an example of this, let’s assume that our application the settings given in the table below:

When the receiver loads this application, it will look for Ticker.class in the following locations:

1. http://www.cnn.com/apps/Ticker/com/cnn/Ticker.class
2. http://www.cnn.com/mhp/Ticker/com/cnn/Ticker.class
3. http://www.cnn.com/apps/Common/com/cnn/Ticker.class
4. http://www.cnn.com/mhp/Common/com/cnn/Ticker.class

DVB-IP and broadband return channels

Even though we can load class files and data files over the return channel, application signalling must still be carried out via the AIT in the transport stream that contains the service. There are several reasons for this, but the biggest one is very simple: every MHP application is tied to a service (possibly more than one service, but this is not really relevant for this discussion). If every application is tied to a service, then it makes sense to include descriptions of applications in their parent services.

This may change when a standard for using MHP on IPTV networks becomes available, and it may be based on the DVB-IP specifications. Work is ongoing on this issue, and a solution is likely to be defined sometime in the future – use of MHP over IP networks is too big an issue to ignore. One of the problems at the moment with using an IP connection for loading classes and data files is that it assumes many people have a broadband return channel. This is not the case right now, and cost pressures are likely to mean that many people will continue to buy receivers equipped with a PSTN modem. Despite this, several telecom operators are looking at combining receivers for digital terrestrial signals and receivers for IPTV services, and these will provide one way to boost the deployment of broadband return channels. As more telecom operators begin to launch IP-based video services, expect MHP to focus more on this area.

Defining custom classloaders

The approaches to class loading that we have seen so far all require us to tell the receiver where to find the classes, usually as part of the application signalling. Sometimes, an application will need to load class files from a location that can not be easily pre-defined, for instance loading different classes based on options chosen by the user, or from a source outside its ‘home’ object carousel or outside the classpath. Java allows us to do this by defining our own classloader and using this to load the classes in question.

A classloader, as its name suggests, is a Java component that provides a standard interface that allows the JVM to load a class file: different classloaders could load classes from a local filesystem, and HTTP connection, or a DSM-CC object carousel. We will not look at classloaders in any details here, and so if you are not familiar with them you may want to look at the IBM DeveloperWorks tutorial on classloaders.

Unfortunately for developers, DVB-J applications are not allowed to define their own classlaoders; allowing this would pose a security risk because there is no guarantee that a classloader defined by an application would have the correct behaviour when loading sensitive classes such as system classes. A malicious classloader could load its own version of system classes instead of delegating the request to the system classloader, and this has too much potential for problems. To solve this, MHP provides its own classloader that offers this functionality while avoiding any security risks.

The org.dvb.lang.DVBClassLoader class allows applications to load class files from outside their ‘home’ carousel. Files can be loaded from another object carousel (although it must be explicitly mounted first) or from an HTTP connection in those receivers that implement the Interactive Broadcast profile of MHP. Other protocols may be supported by the receiver, but these are not mandatory. When we create a DVBClassLoader, we pass it an array of URLs that acts as the classpath for that classloader. These may be a combination of file:// and http:// URLs in any order.

As we have already mentioned, if we wish to load a class from another object carousel, we have to explicitly mount that carousel first. Since the constructor for DVBClassLoader will not accept dvb:// URLs, we need to use a file:// URL instead, which requires an absolute path.

The example code below shows how we can use a DVBClassLoader to load and instantiate a class from an HTTP connection:

// Create a DVBClassLoader

// First, we have to set up the array of URLs that we want 
// to use as our classpath
java.net.URL classPath[2];
classPath[0] = new java.net.URL(
  "http://192.168.1.100/classes/");
classPath[1] = new java.net.URL(
  "http://192.168.1.101/classes/");

// Now we can create the classloader using that search path
DVBClassLoader cl = new DVBClassLoader(classPath);

// Load the main class through our CCL
Class myClass = cl.loadClass( progClass );

// Use reflection to call its main() method, and to
// pass the arguments in.

// Get a class representing the type of the main method's 
// argument
Class mainArgType[] = { (new String[0]).getClass() };

// Find the standard main method in the class
Method main = myClass.getMethod( "main", mainArgType );

// Create a list containing the arguments -- in this case,
// an array of strings
Object argsArray[] = { progArgs };

// Call the method
main.invoke( null, argsArray );