NX is a new technology to make X connections work reliably and fast
even over very slow and low-bandwidth links.
The techniques to make this work are threefold:
- a very efficient compression of normal X traffic
- a very intelligent caching mechanism of transfered data, with
no second transfer of same and only differential transfers of
similar data
- a reduction of time-consuming X round-trips to nearly zero
X itself *could* be very fast over the network. However, in recent
years, application programmers tended to have forgotton the art to
develop X-efficient programs. Thoughtlessly they introduced a lot
of "round-trip" requiring functions into their code.
This is not the place to discuss that subject and Kurt is not an
expert in this: it should suffice to say that a lot of apps "lazily"
require the X server to store information that could otherwise be
maintained at the X client side; this stored information is again
retrieved by the app more than once, each time requiring a
round-trip...
Over narrowband connections (like modems), each round-trip consumes
200-250 milliseconds. Round-trips therefore induce a lot of
non-responsiveness to GUI applications running f.e. over such
links. A round-trip can be invoked f.e. if the remote application
asks the local X server about the exact position of the mouse
(where event handling by the application itself could ensure the
same result.) During the time the application calls Xlib, it has
to idle until the answer arrives. Another example is when
application and X server need to exchange info about available
X fonts.
NX installs "NX proxies" on each side of an X connection. The NX
proxies speak native "X" with their respective X application (this is
the role of the NX proxy at the remote end) or the X server (this is
the role of NX proxy at the local end). These NX proxies cache most
of the X protocol operations
on their own sides, keeping the caches in sync. The NX proxies only
transfer "differences" in respect to previous operations. The NX
proxies apply a very efficient compressed encoding of the traffic
between them, even translating X bitmaps to other more compact
lossless or lossy image formats, like PNG or JPEG.
The NX protocol is based on a modified X protocol, but vaporizing
the many X round-trips down to nearly zero.
To give a few figures:
-
a Mozilla start-up alone produces nearly 6.000 round-trips
and needs more than 7 minutes to complete over a 9.600 baud
modem connection. With the help of NX, the round-trips
are boiled down to a few dozen, and a startup may only take
20 seconds over the same modem link!
-
a full-screen KDE session transfers 4.1 MByte of data over the
wire, if it is run over a vanilla remote X connection. Run it
over NX, and the second startup data transfer volume is down
to 35 kByte only! You
can run KDE sessions over a 9.600 baud modem link and have a
responsiveness which is better than TightVNC over a crosslink
cable hooking together two boxes only 1 yard apart.
-
overall compression/speed gain is 70:1 (on average, across
various applications), but can easily achieve 200:1 and more
for some applications, like Web browsing.
NX has a few more goodies built-in:
-
NX embodies the additional capabilities...
- ...to connect to Windows Terminal Servers or Windows XP
Professional boxes, using the RDP protocol,
- ...and also to connect to VNC servers, using the
RFB protocol.
In these cases the remote NX proxy uses additional "agents"
which speak the RDP or RFB protocols to the remote "foreign"
servers. The NX agents translate these other protocols
to X primitives, hand them to the remote NX proxy which
transfers them down to the local NX client (applying, of
course, its built-in compression and caching
techniques). NX keeps bitmap updates in their foreign format
and translates them into X bitmaps only at X server side,
offering, thus, no penalties compared to the client speaking
the native protocol. The NX encoding and compression of the
resulting X protocol (using its usual algorithms) offer
compression ratios ranging between 4:1 and 10:1 in respect
to the native RDP or RFB protocol.
NX derives its capabilites regarding these foreign protocols
from "rdesktop" and "TightVNC" at the remote end, but
uses an NX connection between the local and remote proxy.
-
NX can share files and printers between the local NX client
machine (running the X server) and the remote NX server running
applications (that is the X clients)
-
NX can tunnel multimedia and sound streams through the
connection
- NX can encrypt all traffic using SSH
- NX can display not only remote "fullscreen" desktops, but even
individual X applications in "single application window mode" on
the local X server display (it makes for
cute screenshots to
put Konqueror or KMail on an MS Windows XP-based desktop
this way)
-
NX utilizes the achievements of other OSS developers by
plugging their components into its architecture: X11, SSH, Samba,
rsync, Xnest, rdesktop, TightVNC, artsd, ESD...
-
NX servers don't install an additional daemon, opening an
addtional port. NX clients connect to the standard SSH daemon of
any given system (usually over port 22) and then start the "nxshell"
(effectively starting the NX server and connecting to it). If an
administrator cares for securing his SSH server, he implicitely
has also cared to a large degree for securing his NX installation.
NX is the starting point for a new understanding of network desktop
computing. It makes it possible to connect to your own Desktop,
running your own application, using your own data from anywhere in
the world even over slow connections like GSM-modems. Not too far
from now, in the near future we will "NX-connect" on a peer-to-peer
basis to remote applications that run on Linux, Mac OS X, Solaris
and Windows application servers somewhere in the world, but are
displayed at our local PDA. NX may soon define an X-based web, just like
HTTP defined a HTML-based WWW.
NX certainly has the potential to take a big share of what now
is one of the strongholds of Citrix MetaFrame/ICA and Microsoft
Terminal Servers.
All the core NX components and libraries are licensed under the
GPL and their source code is freely available. On top of this
GPL-ed, self-developed code, the originators from "NoMachine.com"
have built a proprietary, commercial product, called the NX Server
and the NX Client.
This suite of software aims to be a open-standards based replacement
of costly solutions, which use proprietary technologies. NX server
and client software can effectively help with the adoption of Linux
on the desktop, They offer to corporates a valid Unix alternative to
Microsoft's and Citrix's stronghold on thin-client computing.
That's why they are also mentioned in the "Migrationsleitfaden"
published by the German Ministery of the Interior.
NoMachine.com have invited the Open Source Software community
to develop their own, compatible versions of NX-based clients and
servers. They promised their help and active support for that
effort. They pledged to not use any different, superior libraries
for their commercial product (unlike f.e. other hybrid
OSS/closed-source projects do -- why is it that in Kurt's mind
there always appears CrossOver/WINE as an example? ;-) and
to always release future versions of these libraries under the
GPL.
The talk will provide a practical demonstration of NX. At the
beginning we will connect to an NX server in Italy, and run
the local OpenOffice.org presentation from there, displaying it
in the conference hall to the audience. It will include a
demonstration of a commandline-based connection as well as the
GUI-based "NX Client" one. Prepare for some more surprises!
[
Kurt hopes, that this presentation will help to find interested
developers which then start to work on a Free NX Client and Server
(just as a few years ago his evangelism regarding CUPS had
helped to spawn the development of the KDEPrint GUI for
CUPS.... ;-) ]
|