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.
How Effective Is NX?
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.
Other Protocols: RDP and RFB
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>

Complete Desktop or Single Application Windows
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.

Session Detaching and Reconnecting
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.
Printing
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.