NX technology

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

Lua error in package.lua at line 80: module 'strict' not found.

NX technology
Initial release 2002
Stable release 6.0.62 / 14 November 2017; 6 years ago (2017-11-14)
Size 28 MB
Type Remote desktop software
License Freeware
Website www.nomachine.com

NX technology, developed by NoMachine,[1] and commonly known as "NX" is a proprietary computer program that provides desktop and remote access. It consists of a suite of products for desktop virtualization and application delivery for servers, and client software.

Features

The software can be installed on Windows, Mac, Linux and Linux ARM. Client software is available for Windows, Mac OS X, iOS, Android, Linux, Linux ARM and HTML/JavaScript permitting access from any device or computer. Features include: sharing network devices, session recording, file transfer, multi-media capability and browser-based access.

Additionally, the enterprise-oriented server products offer multi compute-node clustering and fail-over functionality, as well as the ability to run multiple virtual Linux instances on the same machine (Linux Terminal Server functionality).

The integration of VirtualGL means high-end OpenGL-based X applications and 3-D CAD programs are rendered and displayed with the best possible accuracy.

NX, or NoMachine as it is often referred to since the release of version 4, is environment-agnostic in that it operates with any physical, virtualized or in the cloud server infrastructures, i.e. it can be installed on Linux, Windows and Mac instances virtualised on top of popular hypervisors like Xen, KVM or VMware or integrated with any Virtual Desktop Infrastructure running in private or public clouds, such as Amazon EC2 or Rackspace.

Brief history of NX

In 2001, the compression and transport protocol NX was created to improve on the performance of the native X display protocol to the point that it could be usable over a slow link such as a dial-up modem. It wrapped remote connections in SSH sessions for encryption.

The NX scheme was derived from that of DXPC – the Differential X Protocol Compressor project. NX 1.x was released to the general public on February 14, 2003, the final version of 'NX' being 3.5. The last update of 3.5 was in 2012.

The core compression technology up until NX 3.5 was made available to the community under the GNU GPL2 license whilst other components such as the NX Server and NX Client programs were proprietary.

In 2009, Google made a freely available Open Source GPL2 version of the server called Neatx. Other open source variants of NoMachine's NX are also available (see below).

Starting in 2013, with the release of version 4.0, NX technology became closed source.

Technical details of recent versions

Starting from version 4 of the NoMachine products, NX technology, originally based on X Window System compression, has evolved and combines experiences in image compression and caching with the use of the latest techniques of video encoding.

Client applications can connect using the SSH protocol, with the same authentication mechanisms as version 3, or a new SSH system login or by using the new SSL-enabled NX daemon. Once the secure connection is established, clients negotiate a desktop session by means of a text protocol compatible with the one used in version 3. Or a client can use one of the various NoMachine sub-systems, such as the file synchronization service, software updates, directory services, voice/video messaging and server clustering.

When connecting different hosts across the network, the NX protocol works as a generic tunnel, but as one with additional framing and flow control information, used to dynamically adapt compression and bandwidth in real-time, according to the network congestion and capability of data transfer. To preserve compatibility, multiplexing is based on the same version 3 schema.

NX 4 adds new channel types to handle additional services such as the new file-system redirection, new printing system, virtual network interfaces, smart-cards and USB devices. Most NoMachine components, including the agent program impersonating the desktop session on the server, embed so called "slave servers". These are light-weight servers providing inter-process communication and automation services which can be used to create additional channels, under the control of the client and the server.

Applications can still request channels to carry data using the NX X Window System protocol compression. Version 4 adds new channel types for display and audio, allowing for multiple codecs in the same stream. Currently, the display channels can handle data in H.264, VP8, MJPEG and other formats, with additional primitives used to implement special encoding operations besides the standard audio and video streams."

Once the session has been negotiated between the client and the server, NX data can travel on TCP and UDP streams. The client and server select dynamically what transport to use, based on the type of data and the network conditions. If communication over UDP is enabled, client and server can automatically instruct the router to open the necessary ports. UDP uses symmetric Blowfish encryption. Host interface and port, as well as the Blowfish encryption key, are negotiated using the secure TCP link. UDP communication is disabled when using SSH tunneling, so that all data goes through the same SSH link.

The display protocol uses a combination of video and image encoding, based on standard codecs and a number of techniques developed by NoMachine. NoMachine monitors the content of the display and the user activity to adapt quality and buffering to the displayed application. In this way NoMachine can automatically adapt to widely different use-cases and scenarios.

Authentication

From version 4.0 onward, when the default NX protocol is used, the login can be via password-based authentication, private key or kerberos ticket authentication.

When NX is configured to send its data by the SSH protocol (SSH authentication is available only on enterprise-version servers), the following methods of authentication are available:

Client to Server

  • NX login as nx user using the NX SSH key and user password based authentication on the system.
  • System login with password based authentication.
  • System login with SSH key based authentication.
  • System login with SSH key based authentication and SSH key stored on a smart card.
  • System login with Kerberos ticket existing on client side.

Server to Node

  • Login with password.
  • Login with SSH key forwarded from client (e.g. NoMachine Player) via Server to Node.
  • Login with Kerberos ticket forwarded from client via Server to Node.
  • Login with Kerberos ticket requested on Server host by Kinit on server host.
  • Login with Kerberos ticket requested by PAM module on Server host.
  • Login with password to Kerberos ticket requested by PAM module on Node host.

Technical details of legacy version NX 3 and earlier

NX compresses the X11 data to minimize the amount of data transmitted. NX takes full advantage of modern hardware by caching all manner of data to make the session as responsive as possible. For example, the first time a menu is opened it may take a few seconds, but on each subsequent opening the menu will appear almost instantly.

NX is faster than its predecessors, as it eliminates most of the X round trips, while dxpc and MLView only compress data.

The two principal components of NX are nxproxy and nxagent. nxproxy is derived from dxpc and is started on both the remote (client in X terminology) and the local (server in X terminology) machines simulating an X server on the client and forwarding remote X protocol requests to the local X server.

Simplest Setup:[2]

remote clients (xterm, etc.)
            ↕
      nxproxy client
            ↕
         Network
            ↕
      nxproxy server
            ↕
local X server (monitor/keyboard)

nxproxy alone achieves 1:10 to 1:1000 compression ratios[3] reducing bandwidth, but does not eliminate most of X's synchronous round trips, which are mostly responsible for X's perceived latency.

nxagent in turn is derived from Xnest (similar to Xephyr) and is typically started on the remote (client) machine, thus avoiding most X11 protocol round trips. Together with nxproxy (which is built into nxagent) this setup performs well over low bandwidth/high latency links:

Typical Setup:[2]

 remote clients (xterm, etc.)
            ↕
  nxagent server side \
  nxagent client side   nxagent executable
     nxproxy client   /
            ↕
         Network
            ↕
      nxproxy server
            ↕
local X server (monitor/keyboard)

On systems with a functional X11 implementation, nxproxy and nxagent are all that is needed to establish a connection with low-bandwidth requirements between a set of remote X clients and the local X server. SSH can be used to establish a secure tunnel between the two hosts involved. NX 3 relies on both the SSH functionalities and the existing open-source SSH software, to make it possible to run contemporary Unix and Windows desktops and arbitrary network applications, across the Internet, in a secured and controlled way.

FreeNX and the various NX Clients are used for setup, handling suspend and resume, secure tunnelling over SSH, and for printing and sound.

Other display protocols

All Enterprise versions of NoMachine's NX protocol allow client connections to hosts via Remote Desktop Protocol (for Windows Remote Desktop Services sessions) and remote Virtual Network Computing sessions (most modern general-purpose operating system platforms) as well as XDM.

License

Prior to version 4.0, NoMachine used the GNU General Public License for the core NX technology, while at the same time offering non-free commercial NX solutions for the enterprise,[4] free client and server products for Linux and Solaris and free client software for Microsoft Windows, Mac OS X and embedded systems.

On December 21, 2010, NoMachine announced that the upcoming NX 4.0 release would be closed-source only.[5]

Due to the free software nature of older releases of NX, the FreeNX project was started in order to provide the wrapper scripts for the GPL NX libraries.[6] FreeNX was developed and maintained by Fabian Franz, but has not made a release since 2008.[7]

2X Software developed another commercial terminal server for Linux that also uses the NX protocol.[8]

On July 7, 2009, Google announced their open-source NX server, Neatx.[9] Neatx was developed as part of an internal project[which?] which has now finished, had no releases and is not being actively developed. The source code is available under the GNU GPL v2 license.[10]

X2Go is based on the 3.x NX libraries, but is not compatible with other implementations.[11][12] The client and server are released under a combination of GNU GPLv2 or later, and GNU AGPLv3 or later.[13]

Clients

The primary clients for use are the official freeware, NoMachine and NoMachine Enterprise Client, but there are several open source projects which can use the NX protocol.

The most mature of the projects used to be Lawrence Roufail's nxc client library. This is a full library which can be used for other clients to build upon, and another application, 'nxrun', is provided which makes use of this library. As of 2006, the library does not allow suspending or resuming sessions, nor does it use any compression method other than JPEG for the graphics.

The kNX project was a proof-of-concept application written by Joseph Wenninger. This was meant to eventually become a complete NX client, showing that an open-source client could be written. However, this implementation got stuck in an incomplete stage; to date it lacks many important features. As such, kNX was effectively useless. In late 2005, Fabian Franz and George Wright started to change kNX to use the nxc library, but quickly abandoned the project.

More recent open-source efforts include QtNX, which offers full suspend and resume. However, this has been reported not to work with the most recent NX libraries.

An update to nxclientlib (which was the core of QtNX) called nxcl has been completed by Seb James in September 2007. nxcl is an update to nxclientlib and works with version 3 of the NX core libraries.[citation needed] It also drops the Qt dependency which prevented nxclientlib from becoming widely used as a cross-platform basis for NX client programs. nxcl provides both a library which can be linked to in a client program (libnxcl), and a self-contained NX client with a D-Bus API (the nxcl binary). nxcl is available from the FreeNX Subversion server.

Other recent and actively maintained OSS NX clients include OpenNX, a "drop-in replacement for NoMachine's [proprietary] nxclient". OpenNX has full suspend and resume.

Various open source terminal server projects such as X2Go also use the NX protocol; however, X2Go is not compatible with other NX servers and clients.

Another recent GTK+ remote desktop client project, Remmina, announced the ability to use the NX protocol in its release 0.8.

Previous X11 compression schemes

See also

  • Comparison of remote desktop software
  • Thinstation – a thin client Linux implementation with optional built-in NX client
  • GNU Screen – a terminal multiplexer for console-mode (text-mode) applications
  • Xpra – a system for attaching and detaching remote X programs
  • xmove – a tool allows you to move programs between X Window System displays (outdated)

References

  1. Lua error in package.lua at line 80: module 'strict' not found..
  2. 2.0 2.1 Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found..
  4. Lua error in package.lua at line 80: module 'strict' not found..
  5. Lua error in package.lua at line 80: module 'strict' not found..
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found..
  8. Lua error in package.lua at line 80: module 'strict' not found..
  9. Lua error in package.lua at line 80: module 'strict' not found..
  10. Lua error in package.lua at line 80: module 'strict' not found..
  11. Lua error in package.lua at line 80: module 'strict' not found.
  12. Lua error in package.lua at line 80: module 'strict' not found..
  13. Lua error in package.lua at line 80: module 'strict' not found..

External links