Re: [forum] Re: About our effort at NoMachine
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.
[Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Samba] [Linux Security] [Linux RAID] [Linux Resources]