NX Components
OpenFacts, the Open Source Knowledge Database
Below are a few flowcharts (ASCII art type) which attempt to explain how NX technology works as compared to un-accelerated X11 remote access. We start with the flowchart for pure, plain vanilla X(11) traffic:
. .
"Pure" X connection (not accelerated)
###################################################################################
+----------+ +----------+ | | --> responses <-- requests | | | | --> events | remote X | | | X --> errors X |applicat. | | local X | <-------------------------------------------------------> |(or compl.| | display | (many "round trips": request + response pairs) |KDE/GNOME | |(X server)| | session) | | | | | +----------+ +----------+
(c) Kurt Pfeifle, Danka Deutschland GmbH <kpfeifle at danka dot de> ###################################################################################
Note 1: you can make plain vanilla remote access fairly secure by using SSH. Example: run the command like this to start a "konqueror" on "remoteserver" and display its window at your local host's screen:
ssh -X myusername@remoteserver "konqueror"
You can add the "-C" paramter to gain some compression benefit (generic ZLIB compression). Some people still use an X11 extension called "LBX" (Low Bandwidth X). Please note that LBX is deprecated by the creators, since it doesn't compress traffic more efficiently than "ssh -C", but is more unsecure and considerably more complicated to setup and maintain.
Note 2: It helps to improve the "felt speed" of an interactive remote X11 session to some degree, if you can increase bandwidth for X11 connections. But there is a limit, beyond which more bandwidth doesn't improve your connection speed. The reasons are the many roundtrips that are invoked by most modern X11 applications. (X11 by itself is a pretty efficient network protocol with little overhead -- the roundtrips are produced by the applications). You sit in front of a big empty pipe waiting for responses from the remote end consisting of fairly small packets which do not fill the pipe.
. .
NX proxies and nxagent-agent accelerate X protocol transfers
#########################################################################################
+-------+ +--------+
| | | |
| | | |
+-------+ | | | | +----------+
| | | | traffic type: | | | |
| | traffic: | | NX "protocol" | +-------+traffic type:| 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)|
| | | | | | | |
+-------+ | | | | +----------+
| | | |
| | | |
+-------+ +--------+
decompression compression
+caching +caching
(c) Kurt Pfeifle, Danka Deutschland GmbH <kpfeifle at danka dot de> #########################################################################################
NX uses 3 basic methods to achieve its remote desktop and application speed boosting: compression, caching and roundtrip suppression for X11 traffic.
- NX Compression
- NoMachine have developed their own compression algorithm for X traffic. This is about 10 times more efficient than generic ZLIB compression, while using only one tenth of ZLIB's CPU cycles. This is the first secret for NoMachine's NX speedup.
- NX Caching
- NoMachine have also developed a very intelligent caching mechanism for X11 traffic. It produces a quite big "hit rate", sparing the transfer of the same data repeatedly, and restricting the transfer of similar data to a "differential transfer" only. This is the second secret for NoMachine's NX speedup.
- NX Roundtrip Suppression
- Before NX there was no known method to suppress X11 roundtrips over remote links reliably and in a robust way. NX can do that by translating X11 traffic at the remote end (occuring from application to nxagent) into NX protocol traffic. This is the third secret for NoMachine's NX speedup.
Overall efficiency: All 3 methods combined are able to achieve a 70-fold efficiency of working with a remote X11 GUI using the highest level of compression over low bandwidth/high latency links. (Note: the "Modem" compression type [as shown in the NoMachine NX Client GUI] is the best compression, "LAN" setting does no compression at all. You can use "modem" compression in LANs for better efficiency.)
. .
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>
#####################################################################################
Note: similar to the X traffic protocol translation made with the help of nxagent, there is another agent ("nxviewer") that can translate RFB/VNC traffic into NX protocol. This speeds up the efficiency of the connection up to 10 times over small bandwidth/high latency links (compared to direct plain vanilla "vncviewer" access from the local X display to the remote TightVNC Server).
. .
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> ###################################################################################
Note: similar to the X traffic protocol translation made with the help of nxagent, the agent "nxdesktop" translates RFB/VNC traffic into NX protocol. This speeds up the efficiency of the connection up to 10 times over small bandwidth/high latency links (compared to direct plain vanilla "rdesktop" access from the local X display to the remote Windows Terminal Server).
. .
NX proxies complete flowchart (with all agents)
##################################################################################
+-----------+
+-------+ 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>
###################################################################################
![[Main Page]](http://openfacts.berlios.de/images/berliOS_small_logo.png){kind=logo}