This is the first in a seven-part series written by FreeNX Development Team member Kurt Pfeifle about his involvement with NX technology. Along the way, he gives some basic insight into the inner workings of NX and FreeNX while outlining its future roadmap. Much of what Kurt describes here can be reproduced and verified with one or two recent Knoppix CDs, version 3.6 or later. A working FreeNX Server setup and the NoMachine NX Client has been included in Knoppix now for over a year.

Figure 1. A remote KDE session viewed on a local Windows XP Professional desktop using the NX client for Windows. The NX server is installed on the remote Linux machine, konstruct@10.160.47.201, identified at the top left of the window frame.

NX is a new technology that allows one to run remote X11 sessions across slow or low-bandwidth network connections. User experience with NX is one of excellent responsiveness. Users with previous remote X11 session experience are stunned by NX's speed and its snappy application interaction. Moreover, NX also can connect to remote RDP and VNC sessions and offer big performance wins over TightVNC and rdesktop remote access. NX can do all of this from Linux, Mac OS X, Solaris and Windows workstations as well as from some types of PDA gadgets.

Let's first get the yardstick defined. What do I mean by "slow link" or "narrow bandwidth"? People from some corners of the world think of a DSL link with a 384kb/sec connection as low-end connectivity. To them, slower links are not even worth considering. On my own horizon, low bandwidth means ISDN speed (64kbit/sec) down to even GXM modem speed (9.6kbit/sec or 9600bits/sec). A developer spoiled by fast links may not see a need to improve the performance of graphical applications running remotely. For him, X tends to be good enough. But not for me.

Plain vanilla remote X connections suck. I can't really work with them. I used to use them because there was no alternative. They still feel sluggish and unresponsive. Even across a 384kbit/sec DSL link, they are not much joy.

Ever since I saw how well ICA performed across an ISDN line for the Microsoft/Citrix Metaframe Server access, I envied their users. I wanted the same speed and responsiveness for remote X. But every expert I talked to told me, "It's impossible. See, Keith Packard tried it once. He started to create a Low Bandwidth X (LBX) protocol, but even he gave up. Read his farewell document, "LBX Postmortem", and you'll see it is impossible!"

So, I read Keith's conclusive proof, dated January 2001, about this impossible dream. I admit that I didn't grasp all of the technical details of his arguments. I am not a developer; I can't read and understand C or C++ source code, and I am not an X11 expert. I have to trust some third-party expertise or my own user experience with a certain piece of software.

Keith based his conclusions on measurements of real-life applications and real-life networks. He was able to accept even unflattering results--his own baby, LBX, failed to live up to expectations, including his own. LBX would never work better than SSH with ZLIB-compression, he concluded; and SSH with ZLIB-compression already was at everybody's fingertips. So his final recommendation was simply to use something like:

ssh -X -C username@remotehost start-my-X-application.command.sh

where ssh creates the connection and gives you encryption and security, -C gives the best compression you can get and -X forwards X11 output to your local X display.

If someone of Keith Packard's stature says that X network performance can't be improved considerably without drastic changes in the internals of applications, there is no hope, right? At this point, I played nice and gave up asking.

Staying quiet didn't last long for me, however. I gave up only until I by accident came across a posting by Gian Filippo Pinzari. This was more than two years ago, March 23, 2003, to be precise. The posting's title was "About our effort at NoMachine". Directed to forum@xfree86.org, the open mailing list of the then still-united XFree86 project, Gian Filippo detailed the achievements of a group of developers in his company, NoMachine. The group successfully had concluded work on the first version of a new "low bandwidth remote X" application, NX, that the company started to sell as a commercial product. Later, I found out that Gian had sent similar messages to other addressees, including the Linux Terminal Server Project (LTSP), KDE Core Developers, GNOME Developers, RealVNC, TightVNC and the rdesktop mailing lists. The developer communities thus were informed of NX.

In these various messages, Gian hinted at the commercial NoMachine NX Server product. The features he outlined sounded exciting enough, but it was another message I took from his postings that thrilled me the most. It was how he outlined that NoMachine had released its main intellectual property, the core NoMachine NX libraries, under the GPL license. He wrote, "It is there and everybody can use it."

Out I went and installed NX, and I immediately was hooked. The performance was in a completely different league from any other remote X or GUI connection I had seen on Linux.

Even better, I was not restricted to X11 sessions. I also could hook up to a TightVNC server in our company network. At the time, it was hosted on a remote site, wired up with an ISDN dial-in line. Tunneling that VNC connection through an NX proxy link, I experienced a speed increase at least two-fold over a plain vanilla TightVNC link.

Figure 2. A remote instance of the KDE groupware application, Kontact, as viewed on a Windows XP Professional desktop using NX. The Kontact application could be running on a secure, virus-free Linux machine elsewhere in the same office, somewhere in the same town, perhaps in a neighboring country or even far across the ocean on another continent.

Furthermore, NX also let me access a Windows XP Professional box or an MS Windows Terminal Server, which both use RDP (see Figures 1 and 2). Again, with RDP running over NX, performance and response were remarkably better than when going through a flat rdesktop connection.

I started to sense what Gian Filippo had hinted at when he wrote in his announcement mail: "In the future, we envision a world where any application is available to any device, from anywhere in the world. To make this possible we needed efficient transport and compression of X-Window."

In the two years since my introduction to low-bandwith remote desktop access through NX, I have learned a lot about how the X Window System and remote X connections work. I ran some benchmarks with NX, and I became familiar with NX developers. I learned about their development roadmap. I am still not a C or C++ coder, and I still can't understand anything but about half of the comments in C/C++ source files. But what I've learned is worth sharing with you. I have had a lot of e-mail exchanges with NX developers. All of them, particularly the project lead, Gian Filippo Pinzari, have been friendly and patient and have explained things and answered all my many questions.

NoMachine ships with its GPL code a command-line utility named nxcompsh. It serves to establish peer-to-peer NX sessions. On top of the GPL core NX components released by NoMachine, a commercial version of the software is available as the NoMachine NX Server. This version makes installing, configuring and running NX a simple task, feasible for a common user in seconds.

Here is an early summary of how NX achieves its extraordinary performance. We delve into more details in subsequent parts of this article series.

NX combines three essential ingredients:

If equivalent data needs to be transfered repeatedly, NX takes it from the cache. If similar data needs to be transfered repeatedly, NX boils down that action to a differential transfer. What it pipes through the link is not the complete data, but only the delta.

These two techniques are not entirely new. Previous implementations of them exist, but observers might conclude that NX's implementation is more elegant. NX is optimized to the last bit. Keith Packard thought that to go beyond ZLIB's compression was nearly impossible and the result never could perform fast enough. He concluded that roundtrip suppression was an important factor for success. Before NX, roundtrip suppression was never made efficient enough for X connections. And for reasons unknown to me, Keith Packard never pursued its solution. The solution to roundtrip suppression is the most decisive breakthrough represented in NX. It is the missing link in reducing traffic between the NX client and the server enough to facilitate a believable low-bandwidth remote GUI experience. It thus created a new X compression technology that is far better than plain ZLIB.

We discuss more about NX roundtrip suppression and traffic compression in Parts 2 and 3 of this article series.

To learn more about FreeNX and witness a real-life workflow demonstration of a case of remote document creation, printing and publishing, visit the Linuxprinting.org booth (#2043) at the LinuxWorld Conference & Expo in San Francisco, August 8–11, 2005. I will be there along with other members of collaborating projects.