There’s a lot of talk about Google Wave these days and it seems like more and more is getting invented to keep us from ever wanting to leave the browser. Another technology that has not gotten quite as much attention is the Google Native Client, which with help from the open source community is currently being refined after the release about a year ago. I watched an online video about it and was very impressed with what they are doing. The video is somewhat more focused on security measures than on what features will eventually be offered to the end-user, but I recommend watching it to anyone interested in computer science.

For the end-user, Native Client enables secure execution of native code in the browser with very little overhead, which means it’s possible to execute computationally intensive software such as games. Native code execution is already possible through techniques such as ActiveX for Internet Explorer and NPAPI for other browsers, but those techniques can lead to security issues – if you accept execution of a plug-in of this kind it can basically do whatever it wants to your computer, which means you really need to trust the provider before accepting it. With Native Client, you once accept the Google Native Client plug-in to install and after this, arbitrary 3rd party Native Client modules can be downloaded and executed without any warnings or pop-up dialogs. Native Client makes sure (or at least tries very hard to make sure) no bad code is executed. Direct access to some resources such as the file system and network is prohibited for security reasons and this of course to some extent limits what kind of applications can be built without further workarounds.

Quake in the browser

I think Google’s Native Client has a lot to offer to software people. Not many other techniques for browser applications offer the possibility to securely run multi-threaded programs with close-to-desktop-application performance and it kind of provides a shortcut to web applications for those who never bothered to learn the web-specific techniques. Programmers can use code from existing applications and after some slight modifications use the Native Client tool chain to build a corresponding Native Client module that can be run in the browser. The modules are OS and browser independent so once you have ported your application (or built a new one from scratch) it can be executed in any of the supported browsers and operating systems.

The Google team at an early stage ported the classic game Quake to this new platform to demonstrate its capabilities and if nothing else, this technology should open for an online revival of games from the ‘90s. It is very possible however, that the impact of this technology will be bigger than so – Native Client is now built-in to the Chrome browser by default – no plug-in installation required.

A few weeks ago I got a question about using GIPS products for streaming music. This is indeed possible, but since having to wait a few seconds before the play-out starts hardly matters when streaming, you can normally get away with using less sophisticated techniques like buffering a few seconds of audio to make room for delayed packets and have the time to re-send lost packets.

Anyway, the question got me thinking about whether there is a scenario where music played over the Internet would benefit from real-time treatment. I came up with one: what if you were able to rehearse with your band mates over the Internet. Imagine web portals where virtual bands can be formed in minutes – the drummer is in the US, the base player Swedish and on guitar that Korean guy from Youtube. I wondered if this is something we’ll get to see in the future and – as usual with Internet technology – I then found out it is already available. I haven’t plugged in the guitar and tried it out yet and until I have, I will remain a little skeptical since I believe even the theoretical minimum delay introduced by how fast information can travel over a network (speed of light) will come into play when trying to play music together. Nevertheless, it’s a really cool idea and I’d like to be proven wrong about the suspected delay hurdle – chances probably increase if you limit the distance by restricting band membership to people living on the same continent or in the same country or state.

The Java subject has been discussed before on this blog, so I’m not going to repeat why it’s not a good idea to use pure Java for building a VoIP application; let’s just say it’s going to be a challenge for those who try. But if someone has got a Java based architecture and wants to enable or improve VoIP, will they have to throw their existing code away? Of course not – Java can utilize native, capable C++ libraries through the Java Native Interface (JNI) as long as this is supported by the JVM in the target environment. I wanted to ballpark the effort this would require, so I started hacking with the goal to make a VoIP call using a Java application.

I started out by downloading and installing the latest Java SDK for Windows from Sun. I then used a C++ VoIP library that I happen to have access to and chose the API functions I thought I was going to need to reach my goal (information hiding comes as a bonus – you don’t bring stuff into your Java class until you need and fully understand it). After copy/pasting these API functions into a new Java class, making some small adjustments to parameter types and adding the “public native” keywords in front of function declarations, I could use the “javah” tool to generate a C++ header for the glue code.

Some design decisions needed to be made, for example deciding where object specific information should be stored – I for one wanted to keep the data stored in the C++ glue code to a minimum and chose to retrieve member variables from the Java object when needed (JNI provides special C++ functions to do this). Callbacks, i.e. letting the C++ library call into the Java object, also required some thought (I won’t go any deeper here, but I tried it and it worked great). Basically, when all functions in the header file had been implemented by just making the corresponding call into the C++ library we started out with, the C++ glue code could be compiled/linked into a dll and used from the Java class we just wrote through the System.loadLibrary() call. And we’re done!

To conclude, it was only a matter of hours after downloading the JDK before I had made a (very) basic Java based integration of a VoIP library. This is not rocket science and a successful result was expected, but I still got a kick out of being able to type

 
 java MyVoipApp 192.168.200.41

from a command line to get a high quality VoIP call going on the local network. And now that we are in a Java environment, adding a nice GUI should take like 5 minutes, right?

Earlier this year Intel held a Multi-Core seminar in Stockholm. Long story short, their main message was that the free lunch is now over (although participants were actually served  a free lunch during the event).What they mean is basically that software developers have long been able to see their programs run more effectively as processors running at a higher clock speed have reached the market. Heat and power restrictions now make it a better deal to combine several cores (CPUs) on a chip instead of trying to increase processor clock speed.

This means nothing less than a paradigm shift within the software industry. Some compare it to the introduction of object oriented programming. I’d say it’s bigger, because there’s just no way to cheat – an old-school, serial program will not perform any better if you add extra cores to the system. Sure, desktop users might benefit by being able to listen to a tune or watch a movie while using your program. But server owners generally want one application to run with as much capacity as possible – they want all cores to be busy. The key is parallelism. To parallelize your software, you need to find tasks in your program that can be carried out simultaneously. Ideally you will then get a linear relationship between the number of cores and the speed of your program – double the number of cores should give twice the speed or capacity. This is the trick developers of processing intense software are now trying to perform.

So how does this relate to VoIP? Well, it turns out that once audio quality and stability needs have been met, capacity is the next focus of attention for service providers hosting for example conferencing services. And encoding and decoding of audio or video streams are examples of embarrassingly parallel tasks.

Intel’s vision clearly is to keep adding more and more cores to the same chip. Dual and quad core processors are just the beginning of the revolution and it’s very possible you will be able to host a 500 person VoIP conference call on your laptop in a near future. Using existing GIPS software by the way