Re: [forum] Re: About our effort at NoMachine

[Gian Filippo Pinzari <pinzari@nomachine.com>]

On Tuesday 25 March 2003 09:07 am, Keld Jørn Simonsen wrote:

> > The top level software. Everything you can do with NX Client and
> > NX Server can be done by hand, using OSS components. We
> > count on users being lazy.
>
> What is the op level software?

NX server software accepts connections (or, more precisely, is
invoked by SSHD), authorizes the user and starts a session (that
is an agent and the related X clients). NX client software lets user
configure the session, connects to the remote server through SSH,
tells server what to run, starts the local proxy telling it where to
connect and lets user manage the running sessions. NX server
provides a FTP-like interface and can be used as a sort of
distributed DCOP to launch multiple clients inside the same
session. NX server has to take care of user's authentication,
load balancing, set up of X authorization, etc. As you can see
these are very high level functions. All X stuff is OSS, so you
can use ssh to login to a remote Unix host and start a NX
session (nxagent+nxproxy) by hand. Some scripts are made
available as part of NX OSS distribution (check nxscripts).
hey can be used to run NX sessions without using our
commercial software.

>
> Can your code be backported into XFree86?
> Would that be a major task?

Our modifications are currently based on version 4.2.0 of
XFree86 sources and are available at our website as nx-X11
component. Their inclusion into standard XFree86 tree would
be straightforward, although the software is designed to coexist
with the official X distribution and be used, instead of standard
X libraries, when terminal server functionalities are needed.

> Or are there problems with the license (GPL vs X license)?

I don't think it's a problem to have NX as GPL. It's not going to
replace XFree86. Currently only modified libX11 and libXext
are needed. No change is needed to X server as decompression
is made by an external proxy process. Integration with X server
(as in LBX) could take place at X transport layer, without
requiring a special extension.

>
> I think X really needs an optimization of the protocol like that to
> progress.
>
> What did you do? Just compession of the protocol?

No. I'll try to briefly depict how it works:

we made some changes to transport layer in Xlib (OpenDis.c,
ConnDis.c, Xtranssock.c) to have a new semantic of X display.
You can run:

xterm --display nx/nx,link=modem:1000

In this case xterm will create a proxy process that will listen for
connection from a proxy peer running at user's client. In this way
any X client can be NXized. Local (thin client) proxy is run with:

nxproxy remote_host:1000

The local nxproxy will connect to the xterm process and forward
the X traffic to the current display.

Special clients provide support for X (nxagent, based on Xnest), 
RDP (nxdesktop, based on RDesktop of Matthew Chapman) and
RFB (nxviewer, based on TightVNC vncviewer of Const Kaplinsky).
These clients are called "agents" in NXish.

Of course the part that needed more work is nxagent. Being an
Xserver, it is able to resolve locally all the property/atoms related
requests, ensuring that round-trips are reduced nearly to zero.
By integrating fb functionalities, we were also able to get rid of the
many GetImage requests that were required by original Xnest.
A lot of work was also devoted to font handling (to solve the
problems you can find described in the Xnest man page), clipboard
management, handling of expose events (that are mainly resolved
internally to nxagent without the help of remote X server) and a
lot of other things that I don't remember. nxagent can be considered
a better Xnest and is able to run even without X compression.
The main difference in respect to other solutions, like Xvnc, is
that the output of nxagent is still X, a much higher level protocol
than RFB.

Compression of X protocol is due to Xcomp and Xcompext libraries.
 Xcompext provides some Xlib add-ons that let agents compress
images and perform X protocol operations in a way that helps
Xcomp to carry out its job. Agents are Xcompext aware and use
these protocol add-ons. Normal clients are not, so, in this case, it
is Xlib that takes care of compression of images and of of some
other optimizations needed to improve the compression results.

Compression of X protocol is provided by Xcomp. nxproxy is just
a wrapper of this library.

A tunnel can be created between two hosts running:

nxproxy -C :1000

and

nxproxy -S remote_host:1000

The way Xcomp/nxproxy achieves its compression results is
through extensive caching and differential compression of X protocol
requests. Code is an complete rework of the well-known dxpc X
compressor. Project started in 1999 with the name MLView and was
first released as GPL in 2001. Images are compressed through a
handful of methods. The default is currently JPEG and quality
depends on link speed.

Other methods are pluggable. For example RDP and RFB images
are transported to thin client in their original format and decompressed
there, so there is no overhead in respect of running rdesktop or
vncviewer on the client, with the advantage of leveraging the higher
level X protocol primitives, when possible.

A lot of work was devoted to network performances to optimize
the throughput on slow links. nxproxy, nevertheless, doesn't make
any effort to minimize round-trips by itself, this is demanded to nxagent.
Single applications run through a nxproxy tunnel cannot currently
leverage round-trip suppression offered by nxagent. A rootless
nxagent will be available in one or two months.

Xcomp/nxproxy is also able to tunnel SMB and multimedia
channels, so it's possible to listen music from the terminal server
or make available local resources of the thin client to the remote
session, features present in other proprietary products since long.

/Gian Filippo.