The Arrival of NX, Part 4

How (well) NX works.

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"   |       |       |
  |       |        |       |   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 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

					   +----------+      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.


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 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"  |       |       |
|       |        |       |  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 and wrote most of the printing documentation for the Samba Project.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Problem with nxviewer

Marc's picture

I am able to use the NoMachine Mac OS X nxclient to connect to FreeNX on my Linux box and it's fantastic!

I could not however get FreeNX to successfully proxy to a TightVNC server on my Windows XP laptop. It would timeout and nxnode would exit.

So then I tried to invoke nxviewer directly and I got:

Warning: Unable to load any usable fontset
Info: Using image cleanup parameters 0/0/0/0.
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Most significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
CleanupXErrorHandler called
Info: Disconnecting from RFB server ''.
X Error: BadRequest
Request Major code 230 ()
Request Minor code 0
Error Serial #143
Current Serial #143

which is strange because vncviewer (both RealVNC and TightVNC) don't have this problem (although the display has a yellowish hue to it).

Any ideas?

nx viewer...

Anonymous's picture

I am running into the same problem you described above. I was wondering if anyone ever responded or if you were able to figure it out? Are you aware of anyway to enable 'debugging' to see what is going on?



Anonymous's picture

Hi Marc and Glenn, I also have the same problem!!

Session: Session started at 'Sat Nov 4 17:06:03 2006'.
VNC server supports protocol version 3.3 (viewer 3.3)
VNC authentication succeded
Desktop name "sws1"
Connected to VNC server, using protocol version 3.3
Warning: Unable to load any usable fontset
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using shared memory PutImage
CleanupXErrorHandler called
ShmCleanup called
X Error: BadRequest
Request Major code 230 ()
Request Minor code 0
Error Serial #131
Current Serial #131

My name is also Glenn!

Thanks for any information you guys might have!


Great four-part "seven-part"

Anonymous's picture

Great four-part "seven-part" series. So are we ever going to see the rest of the story?

Huge gap between parts IV and V

Anonymous's picture

Parts 1-4 arrived in a flurry now the bandwidth seems to have dropped to zero. When are parts 5-7 coming?

a long lasting arrival

Anonymous's picture

This series looks suspicious. It is not the first
time that slightly veiled NX advertising comes
from the KDE/Knoppix embedded in technical

According to previous reports in c't (the renown
German computer magazine from Heise) NX is a good
product but in the end only marginally quicker
than well established virtual network software.

Neither NX nor any similar products will work well
over an analog modem connection. The 40kbs speed
that Pfeifle considers normal is rather a connect
speed. The normal sustained speed will be around
33 kbs in G7 countries and around 14 kbs in the
Third World and Eastern Europe.

Also note that you cannot just use NX for Windows
to Windows connections. A pricey NX server must be
in between.

Last but not least, the trick seems to be
"compressed, cached and near-zero-roundtrip X
traffic between the NX proxies". Fine but what is
actually hindering Xfree and Xorg to implement the
near-zero-roundtrip in the X server in the first
place? NX has been around for more than one year
even offering free libraries and that key idea has
still to be picked up by X developers. Strange.

Clarifications ...

Fabianx's picture

>According to previous reports in c't (the renown
>German computer magazine from Heise) NX is a good
>product but in the end only marginally quicker
>than well established virtual network software.

The test, which was in iX magazine was made using emacs in single application mode, which had all the roundtrips. Certain things in the article hint to some problems in the setup as Windows as a client with a full desktop was faster than Linux with a single application.

Most of the other "well-established virtual network software" costs money, lots of money. Here you get faster speed than some of the "well-established software" for free.

>Neither NX nor any similar products will work well
>over an analog modem connection. The 40kbs speed
>that Pfeifle considers normal is rather a connect
>speed. The normal sustained speed will be around
>33 kbs in G7 countries and around 14 kbs in the
>Third World and Eastern Europe.

Yes, they do. I've tested it. Yes, it _is_ really slow with 300-400ms latency (much more latency than a modem has), but its still usable.

I used it over a ISDN line and over a modem and it worked. After some time I completely forgot that I was working remotely.

Its also working great over UMTS, which I also saw it with my own eyes and which also has quite some latency and bandwidth restrictions.

Just try it if you don't believe me / us.

I mean do you think I would spent my time developing a free server software, if they technology would suck?

Do you think I would spent my time on a project, which was not working so well for me that I use it everyday myself?

>Also note that you cannot just use NX for Windows
>to Windows connections. A pricey NX server must be
>in between.

There is no-one hindering you to port the NX framework to Windows. It might be even easy - who knows?

>Last but not least, the trick seems to be
>"compressed, cached and near-zero-roundtrip X
>traffic between the NX proxies". Fine but what is
>actually hindering Xfree and Xorg to implement the
>near-zero-roundtrip in the X server in the first
>place? NX has been around for more than one year
>even offering free libraries and that key idea has
>still to be picked up by X developers. Strange.

Well, if it was that easy do you think NoMachine would have spent 7 years of Development on this project - having participated in creation of the two predecessors of NX: DXPC and MLView.

X developers are working on removing roundtrips, but its not that easy.

And you have to keep in mind that Network X is no high priority for X developers - or at least have not been for a loooooong time.

They are talking about 100MB/s and 0.0001 seconds of latency, but NX is talking about 10kBit/s and at least 100ms of latency.

Its a completely different world ...

NoMachine did write to _all_ major OSS projects in 2003 announcing the availability of the free OSS components, but no one stepped up and used it until FreeNX came along.

What would you expect them to do more?

FreeNX is working now so you get everything for free if you want to.

So where is your problem? I really do not understand it, but I must of course admit that I'm biased as still being the main developer of FreeNX.



Outstanding Project, only adulation

tadelste's picture


This series is quite remarkable. Its informative, detailed, well written and has extensive content. I'm also impressed with your command of English, which I believe is not your mother tongue.

Please excuse readers who pick on small details such as capitalization, minor typos, etc. Linux Journal readers are used to a highly polished print version that goes through extensive QA. I think LJ does a good job on the web site considering the medium.

I appreciate your contribution and I believe many other readers do, but they are the silent majority. I hope you will continue to bring us material on NX and also on other technologies on which you work such as the Linux printing and document management topics.

All the best


One Technical Error

Ross's picture

"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."

Dial-up links are 40Kb/s not 40KB/s. So that screen draw will take more like 8 seconds than 1. That is a significant difference!
I am still looking forward to using NX on a broadband connection though.

KB/sec + Kb/sec + kBit/sec + kByte/sec

Kurt W. Pfeifle's picture

"Dial-up links are 40Kb/s not 40KB/s"

Well, I definitely meant to say 40 kiloBits/second, which indeed is the league of dialup modem speed. I usually even spell it out in written statements as "kBit/sec" to avoid any ambiguity. You can check my other writings about that. Dunno why this slipped in this time, though.

So my statement that good modem speed is sufficient for good NX-based remote working is still valid.

If you have broadband like 384 kBit/sec -- fine. NX will work even better for you then.


Well, he didn't say that draw

Anonymous's picture

Well, he didn't say that drawing the screen would have taken 1 sec.
He said that "If users can have a network bandwidth of at least
40KB(b)/sec [...] they will feel unhindered by network-induced
slowness during remote access."

I can confirm that this is true. Fortunately the screen seldom needs
to be completely redrawn and NX seems to store a lot of information
about the pixmap content, so often it only needs to copy from the
pixmap to the screen.


John Springer's picture

I am living in Phuket in Thailand. Allthough we can get ADSL here ... this 40K is really the top of the speed-scale, because of the very bad phonelines here. Greetings.

Re: 40K-Sek

Alex Malukko's picture

It is always the same in the 3rd-world-countries. DSL-Lines got cut, when it is "raining". Hey, when I was living in Europe I didn't get a slower connection only because of rainfall 8-)

Impressed (really)

Peter v. N.'s picture

As a long time MetaFrame admin, I was really stunned (I must say appalled) by the performance of NX!
I installed/tested the OpenSource version on a CRUX Linux server
(give this distribution a try, simple & clean -> and it worked.
Had to dig thru the docs and read a lot. But once you got it, it's simple...

A big thank you to the NoMachine crew in Rome for the technology and
Kurt Pfeifle for this series and spreading the word. This one is really a killer app.

ASCII flow charts

Keith Daniels's picture

I am working on fixing them. They should be corrected soon.

-- Webmaster

All the new OSs and windowing systems are oriented towards content consumption instead of content production.

--Steve Daniels 2013

Fixed soon? Or forgotten?

Anonymous's picture

"They should be corrected soon."


I would like to believe that. But given the fact that I read this already 10 hours ago, it seems like that noble promise was forgotten in the meanwhile.

Oh, well.

Thanks to the link to the good version on the Berlios website, I was able to understand them well enough.

Not forgotten...

Keith Daniels's picture

The law of unintended consequences got me. One of our newly upgraded security systems blocked me from modifying that file. Since I didn't install it, and the person who did isn't around, it took me a while, digging through logs and experimenting, to find what was causing the problem. Once I got that fixed it only took a few minutes to fix the ASCII problem.

Now I have to find out why it screwed up the ASCII in the first place, which is another one of those "fun" problem.

Sorry it took so long.


All the new OSs and windowing systems are oriented towards content consumption instead of content production.

--Steve Daniels 2013

If it's a proxy, can two people collaborate on the same desktop?

Marekk's picture

If this is a proxy, can two people collaborate on the same remote desktop?

For example, user Joe works remotely on his spreadsheet, and whenever he feels lost, Admin Bob connects from the other location to help Joe solve his problems with that spreadsheet?


PJ Syred's picture

Nice article - very interesting indeed. I've been looking for a good way to unify administration of both remote Windows and Linux machines.

I found the diagrams a bit hard to read though - you might want to consider drawing them again using Dia in GNOME or similar.

ASCII art diagrams totally broken

Anonymous's picture

These ASCII art diagrams are totally b0rken.

I know Kurt draw them correctly. You can see them here too:


So I wonder why a "quality content" medium such as LinuxJournal is so neglecting with their online publications. This is embarrassing for the author as well as for the publisher.

Mangled diags

SamHiser's picture

As editor of this series for Kurt, I take responsibility for these mangled diagrams. The team at LJ is not to blame as, like Kurt, they are on the road at LinuxWorld and have larger concerns presently. We appreciate the effort which particularly Heather Mead has put into editing and managing his unusual series and have no fear the diagrams will soon look well.

Use InkScape

Anonymous's picture

Yes, the diagrams sure need some enhancements. It is a shame to have such an excellent article with pretty bad diagrams. I would use InkScape. It would be great.

Broken ASCII art diagrams

Anonymous's picture

"diagrams sure need some enhancements"


Yes, I am totally embarrassed by the way they appear in this website.

But for me, it is more the website that needs repair.

I am sure to have sent them off unbroken, and somewhere in the process of editing the article (not always to my total liking) they totally messed the diagrams up, and obviously didn't check the website at all.

"I would use InkScape."


Would you like to help with that? Would you draw them for me? I am not a savvy Inkscape wizzard.

BTW, I *do* know Inkscape, and in fact, I just saw that my scripted "nightly builds" have successfully finished building the latest KDE-3.4.90SVN, Scribus-1.3CVS and Inkscape-0.4.3CVS :-)

Kurt (the embarrassed author)

Don't be embarassed.

Anonymous's picture

In the purest *acker tradition, tidying up broken ASCII diagram is one of those ancient practices which brings great pleasure and actually makes us understand better the diagrams.

The suggestion about graphics programs is useful, though, not just because of visual quality but because it's easier (you just provide a png for publishing).

BTW, let me thank you, pointing out that this is one of the best articles in the last few years -- and obviously, Mr. Pinzari et codevelopers also have something to do with all this ;-)

Best regards!