The Arrival of NX, Part 4
This is the fourth 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. In Part 4, Kurt explains how NX interoperates with Windows Terminal Services and VNC remote setups. Much of what Kurt describes in this series 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.
Part 1 is here, Part 2 is here and Part 3 is here.
The work of NX is done through a variety of components. Installing them is extremely easy, but understanding how they interact is more demanding. NX sets up two proxying systems. One such system, the NX Client, is on your local computer. The other system resides on the NX server.
Both proxies talk to each other using the NX protocol. The NX protocol is based on X11. However, it implements a few special extensions that provide for functions that produce compressed, cached and near-zero-roundtrip X traffic between the NX proxies.
NX Proxies and nxagent-agent Accelerate X Protocol Transfers
+-------+ +--------+
| | | |
| | | |
+-------+ | | | |
+----------+
| | | | traffic type: | | traffic
| |
| |traffic:| | NX "protocol" | +-------+ type X:
| remote X |
| | X |local | (internet, modem) |remote |nxagent|
protocol| applicat.|
|local X|<------>|nxproxy|<----------------->|nxproxy|
<-------------->|(or compl.|
|display| | | "roundtrips" | | |
| KDE/GNOME|
| | | | close to zero | +-------+
| session)|
| | | | | |
| |
+-------+ | | | |
+----------+
| | | |
| | | |
+-------+ +--------+
decompression compression
+caching +caching
(c) Kurt Pfeifle, Danka Deutschland GmbH <kpfeifle at danka dot de>
The local (NX client) proxy talks to the local X server. It translates the NX protocol back to X11. That means, no change to the local X server is required to let NX work with it.
The remote proxy (at the NX server end) talks to the remote X11 application. There, it also uses X11 as a protocol. This means that on the remote end no modification is required for the X11 applications to work with NX.
The remote NX proxy poses to the X11 application as if it were its X server. This is where all the roundtrips take place and it is also where they are "resolved." As the roundtrips happen on localhost of the remote end, they are resolved quickly because they use fast UNIX domain sockets.
What the remote proxy incorporates is a kind of shadow X server. It has no physical display attached to it. That part is called the "nxagent". Once nxagent, which to the X application appears to be its X server, receives drawing commands and other X11 requests, it sends them over to the local nxproxy. It has to translate X wire protocol to the NX wire protocol. The NX wire protocol no longer contains many roundtrips. It now carries only compressed data or references to cached elements or differential transfer payload.
Both local and remote proxies store their own caches of transferred data. These caches must be kept in sync. Only when in sync are they useful for saving the second and all consecutive transmission of pixmaps, icons, X primitive drawing elements and so on.
The nxagent part of the remote NX proxying system originally was derived from Xnest. Although While nxagent was heavily modified, even some would say completely re-written, its behaviour is similar to the more familiar Xnest.
Xnest is a special X server that ships with all recent XFree86 or X.org releases. In its standard version, Xnest runs "nested" in a normal X server. To the user it appears as a window on the desktop. This window contains the root of another X server. The Xnest window can embed and display any GUI of an X11 client program. Xnest looks like the real server to its own X clients, and it looks like an X client to its embedding X server. This way, it is acting as an X client and an X server at the same time.
The nxagent has modified the original Xnest code heavily to make it a useful component of the NX proxying system. In addition to serving as a shadow X11 display to the remote X11 clients, it also translates X11 wire protocol to NX requests and handles compression and de-compression of traffic.
At first glance it may seem as though NX introduces a significant overhead; however, the net result of NX still is an overall speed gain for remote sessions. This claim is supported by the following data:
a full-screen KDE 3.2 session start-up sequence transfers 4.1MB of data over the wire, if it is run over a plain vanilla remote X connection.
if run over NX, the second start-up data transfer volume drops down to 35KB, due to the combined compression, cache and minute differential effects of NX.
If users can have a network bandwidth of at least 40KB/sec for each of their remote sessions--that is, something equivalent a modem dial-up link--they will feel unhindered by network-induced slowness during remote access.
The remote NX proxying system is not limited to links with X11 applications. It also can handle two more types of connection requests: Remote Desktop Protocol (RDP) sessions used by Windows Terminal Servers (WTS) and Remote Frame Buffer (RFB) sessions used by virtual network computing (VNC) servers.
Similar to the role of the nxagent, which translates X11-to-NX protocol requests, two separate agents handle these other two protocols. nxviewer is responsible for RFB-to-NX protocol translations. It s based on vncviewer from the VNC development community. nxdesktop is responsible for RDP-to-NX protocol translations; nxdesktop is based on Matt Chapman's rdesktop.
Both these connection types get a significant speed boost if tunneled through an NX connection. They reap the full benefits of NX caching and compression functions for bitmaps. There is no need to eliminate roundtrips.
The local NX proxying system has no need for additional components. What arrives as NX is translating into X at the local end, regardless if it was RDP, RFB or X at the remote end.
The overall efficiency gain for RDP and VNC sessions across slow and low bandwidth connections is at least 2:1 and climbs up to 10:1, depending on the exact parameters of the environment.
Of course, for most enterprise-level use cases, RDP connections accessing Windows Terminal Servers are likely to be the most important ones. Being able to speed up plain rdesktop access by factors from two to 10 times is a big win, bringing the system into the same speed league as Citrix Metaframe/ICA links.
NX Proxies and nxviewer-agent Accelerate VNC Transfers
+-------+ +-------+ | | | | | | | | +-------+ | | | | | | | | traffic type: | | | |traffic:| | NX "protocol" | | | | X |local | (internet, modem) |remote | |local X|<------>|nxproxy|<----------------->|nxproxy| |display| | | "roundtrips" | | | | | | close to zero | | | | | | | | +-------+ | | | +---------+ | | | | | <--. | | | | | | \traffic: +-------+ +-------+ +-----|-+(agent)| \ RFB |(Tight)| decompression compression| nxviewer| `------>| VNC- | +caching +caching+---------+ |Server | +-------+ (c) Kurt Pfeifle, Danka Deutschland GmbH <kpfeifle at danka dot de>
NX Proxies and nxdesktop-agent Accelerate RDP Transfers
traffic: +---------+ +----------+ RDP |Windows | |nxdesktop | ,----->|Terminal | +-------+ +-----|-+ (agent)| / |Server or| | | | | | |/ |XP Prof. | | | | | | <--' +---------+ +-------+ | | | +----------+ | | | | traffic type: | | | |traffic:| | NX "protocol" | | | | X |local |(internet, modem)|remote | |local X|<------>|nxproxy|<--------------->|nxproxy| |display| | | "roundtrips" | | | | | | close to zero | | | | | | | | +-------+ | | | | | | | | | | | | +-------+ +-------+ decompression compression +caching +caching (c) Kurt Pfeifle, Danka Deutschland GmbH <kpfeifle at danka dot de>
For remote UNIX/X11 sessions, you can choose one of two basic modes of operation, a complete KDE or GNOME desktop session or a single application window mode. For the complete desktop session type, you can configure to use either a full-screen or a windowed mode. Windowed mode supports customizable sizes; you can go for an arbitrary portrait 1017 x 666 pixel mode, or whatever you may find suitable. Here, a window of the selected size contains your complete remote KDE or GNOME session. It looks very much like a VMware session running in a window on your desktop. The complete desktop mode is the faster one.
Single application window mode places a floating window displaying a single remote application, such as Konqueror or KOffice, onto your local screen. If you run Windows XP on your local machine, this looks similar to the screenshots shown here. You also could start off by displaying an xterm on your local desktop while running on a remote host. From inside the xterm, you could start The GIMP. All of The GIMP's windows pop up freely floating on your local display--not corralled into another window--much as if you were running the local version of The GIMP on a Linux box.
This single application window mode up until recently worked a bit slower than the complete desktop mode. This changed as of last month's 1.5.0 release of the NX Core library by NoMachine. However, the Knoppix versions you may be playing with to get FreeNX going still will have the older versions for a while).
The reason for the slowness is the single application window mode still has to work without the support of the remote nxagent. As you remember, nxagent is derived from Xnest. But Xnest currently is missing support for a rootless window mode. Single application windows would need that rootless window mode to be able to shake off their roundtrip loads when going through Xnest/nxagent. Because those single application sessions must bypass Xnest/nxagent, they can't benefit from the roundtrip elimination usually accomplished by nxagent.
With the 1.5.0 release, NoMachine's NX developers successfully have included roundtrip elimination into single application mode as well.
Having the ability to disconnect a session and reconnect again has been the "Holy Grail" of X11 remote applications. We've always lacked a reliable mechanism to do this, even though it is an important function. In fact, despite the painfully slow performance of remote VNC connections, the single feature making VNC worthwhile for most of its users is you can detach from a running session for a long period of time and then re-attach to find it in the same state as before. NX and FreeNX have been supporting this feature for quite some time already. It works great with most versions of (Free)NX included in recent Knoppix releases.
There are a few restrictions, however. You can't reconnect from a different workstation if it has a different local display resolution and color depth. But most users are happy, so long as they can at least re-connect from their own workstations. There is no need to fear that some accidental network problem will take down the link and cause a session loss, which would take with it all data in the open remote document on which one might be working.
Based on session suspension and resumption, a session migration feature now is included. I can detach from my running NX session, leave work early to go out for dinner with some friends. Later, from my home PC, I simply re-connect to my NX server and finish the work I interrupted.
NX supports printing from the remote session to your local printers already. It works great. However, it still requires some manual printer configuration for each session's setup. This week, during the LinuxWorld Expo in San Francisco, The FreeNX Team will demo a new way of remote printing. It will be one of the major showcase presentations at the Linuxprinting.org booth (#2043) in the .ORG Pavilion. Using the excellent CUPS framework, any remote application can see and access any printer attached to the local NX client machine. And this works with no extra user configuration whatsoever. You can print from your local workstations without a (Free)NX session running. Start an NX session and you will see the exact same printers there.
This week at LinuxWorld, the FreeNX Project is making the official release of FreeNX-0.5.0, "The LWE San Francisco Release -- Seamless Printing Edition". Demos of the new Seamless NX Printing feature also incorporate interesting collaborative workflows from other projects at the booth. Please come by and see us.
The next installment of this series, Part 5, will take you through some of the details of setting up and using a (Free)NX server and the NoMachine NX Client.
NX Complete Overview
+-----------+ +-------+ RDP |Windows | |nx- | ,---->|Term. Serv.| +-------+ +-------|desktop| / |or XP Prof.| | | | |(agent)| / +-----------+ | | | | <--' +-------+ | | | +-------+ +----------+ | | | | traffic type: | | | | | |traffic:| | NX "protocol" | +-------+ traffic: | remote X | | | X |local |(internet, modem)|remote |nxagent|X protocol| applicat.| |local X|<------>|nxproxy|<--------------->|nxproxy| <---------->|(or compl.| |display| | | "roundtrips" | | | | KDE/GNOME| | | | | close to zero | +-------+ | session)| | | | | | | | | +-------+ | | | +-------+ +----------+ | | | | <--. | | | |(agent)|\ traffic +--------+ +-------+ +-------|nx- | \ RFB |(Tight) | decompression compression |viewer | `------->| VNC- | +caching +caching +-------+ |Server | +--------+ (c) Kurt Pfeifle, Danka Deutschland GmbH <kpfeifle at danka dot de>
Kurt Pfeifle is a system specialist and the technical lead of the Consulting and Training Network Printing group for Danka Deutschland GmbH, in Stuttgart, Germany. Kurt is known across the Open Source and Free Software communities of the world as a passionate CUPS evangelist; his interest in CUPS dates back to its first beta release in June 1999. He is the author of the KDEPrint Handbook and contributes to the KDEPrint Web site. Kurt also handles an array of matters for Linuxprinting.org and wrote most of the printing documentation for the Samba Project.
