Slashdot Mirror
Proxy Servers Lighten Up X
An anonymous reader writes "LinuxDevices.com is reporting on a compression and differential proxy scheme for X that makes it practical to xhost rich applications like Mozilla or a whole UNIX desktop over a 9.6Kbps connection (think cell phone with GSM modem). The company developing NX has a neat test drive set up -- and it is way zippier than VNC. There'll be a paper about it at the next LinuxKongress in Saarbrucken, Germany, and a call is out to OSS programmers to build on the GPL'ed NX library."
Well, noone said you'd run your x apps on your mobile, but you might be connected to your office server on your laptop _via_ your mobile, ie 9k6bps...
./ effect has passed, maybe even I can get a glimpse of the future...
when the
use me... abuse me...
Uh, you use the cellphone as a mobile modem for your laptop. Which can display X just fine.
One simple answer: ssh.
Doesn't matter how you connect to the machine that'll run the program, it'll tunnel all your X stuff over the existing ssh connection, so you don't have to worry about anything. I was stuck on Windows machines sometimes with an X server, and putty handled X tunneling perfectly. Just a checkbox to click and then it worries about the rest.
Stop messing with "export DISPLAY=xxx.yyy.zzz.aaa:0" already...
Maan
UK UNIX User Group
Linux Conference 2003
The NX Project
What is NX?
- NX is a remote desktop system based on X-Window
- Adds features to X-Window usually found in proprietary systems like MS RDP and Citrix ICA
- Makes possible to run contemporary Unix applications over the Internet
- Compresses the X protocol by an average factor of 50:1 and more
- Allows users to work comfortably on 28.8Kbps or even 9.6 Kbps modem connections
- Reduces X protocol round-trips nearly to zero
- Implements image streaming algorythms to reduce the perceived latency
- Is able to translate RDP and RFB foreign remote desktop protocols to X
- Runs these foreign remote desktop sessions faster than their native protocols
- It integrates with SMB to provide access to the client's file systems
- It integrates with ARTSD and ESD to allow media playback
- Adds server management tools to handle X, RDP and RFB sessions run by users
- Architecture is designed to distribute the server workload between multiple nodes
- It leverages SSH remote execution capabilities to avoid the need to run a new network server
- It is able to encrypt and protect the network traffic by tunneling the connections through SSH
- Server is intended to run on any Unix OS
- Client runs on Linux, Windows, Solaris, Mac OS/X, Sony Playstation/2, MS Xbox and embedded devices like HP/Compaq iPAQ and Sharp Zaurus
- NX core components and X compression libraries are released under the GPL license
- NX client GUI (nxclient) and the NX server manager (nxserver) are commercial software
- The NX client-server protocol is open
- A library handling the client-server protocol and a compatible command-line NX client have been released under the GPL license
- NoMachine has publicly offered its help to let OSS developers build a free implementation of both the nxclient GUI and the nxserver NX System Architecture X NX "protocol" (internet, modem) Local X display Local NX proxy system Remote NX proxy system Remote X application Windows Terminal Server, XP Prof. (Tight) VNCServer nxagent (based on Xnest) nxdesktop (based on rdesktop) nxviewer (based on vncviewer) RDP X RFB
What features are missing?
- X session persistence and reconnection - Better support of RENDER extension - Better support of X applications in seamless mode
- Better support of SMB file-sharing and printing
- Seamless access to client's peripherals and devices
- A new multimedia architecture with native streaming of media formats
- Better integration with Unix and Windows desktop environments to allow point-and-click remote execution of applications
- Better server management tools, including a Web administration interface
- An open API to let customers and developers to write server extensions What NX would like to become?
- A convenient way to let users of mobile phones and other thin devices to get access to complex, rich applications
- A server infrastructure by which people can easily run applications regardless they reside on the local machine or a remote server
- A peer-to-peer computing environment where users can easily access computing resources, like storage and printers, on any server available on the Internet
- A step in the direction of the "network desktop" envisioned by many
Keith seems to believe that the solution to X performance issues lies in the clients; and in the long run this may very well be true. However, NX takes the old proxy/agent paradigm pioneered by LBX and dxpc and does something useful with it finally.
Did you RTFA?
NX places a caching proxy server on either side of X's client-server architecture, reducing network traffic to differential transfers of whatever is not already cached. The company says programmers rarely optimize X applications for low throughput on the X client-server interface, resulting in many needless "round-trip" data transfers that NX can largely eliminate.
So instead of taking the whole X session and cramming it over ssh (even with compression) you cache the majority of it and just pass the deltas.
It has ssh capability so I imagine you can tunnel it but you would still be tunneling a LOT less traffic.
You don't have very much experience working in a corporate Unix environment, do you?
Who would use it? Every corporate I.T. dept on the planet which has Unix or Linux installed somewhere.
We have 400 hardware and software engineers who's only access to Unix is a Gnome login. Everything they do is remote to arrays of rackmounted Unix boxes. It saves a fortune every year.
Government of the people, by corporate executives, for corporate profits.
GPRS and HSCSD are just extensions to GSM. My GPRS and HSCSD phone is a GSM phone. As for HSCSD getting 56.6Kbps - that's not quite right - it gets upto 28.8kbps - the most it can manage is the equivalent of 2 simultaneous calls witho9ut the voice error correction. GPRS is about 64kbps but more often 20kbs, EDGE is hardly rolled out yet but practically it should acheive around 64kbps although the theoretical max is 384kbps.
The speeds with HSCSD and GPRS are from my own personal use and in the UK only orange offers both. No other mobile net in the UK offers HSCSD.
Matt Thompson - Actuality - Insert product here.
Citrix MetaFrame/ICA.
Citrix is traditionally known for connecting X to Windows desktops, but they make a product that compresses X11-to-X11 as well.
The good news? It kicks butt. You can feel a lag, but it works far better than anything else I've tried in the speed department. In particular, Acrobat reader renders VERY quickly, and that program is a pig with bitmaps.
The bad news? It kicks butt by compressing the event stream... in a lossy manner. I have seen all sorts of minor glitches, such as menus opening up underneath their parent windows. But some programs are unusable - the Sun Java machine is an example - certain dialogs require a triple-click to select something because somehow Citrix consumes the other clicks.
The bottom line? If you want a solution for the office environment, then this is worth looking into. (Not free, however.) When evaluating, check ALL of your apps to see how bad their lossy event handling will bite you.
I don't know about NiftyTelnet, but if you're on OS X, the plain command line ssh (openssh) should do it. If it doesn't work at first, try ssh -X to force X tunneling.
SSH tunnels at the IP level and can tunnel any connection. It sets up a listening socket on a specified port on one side, and repeats everything it hears on that port to the other side. X tunneling is just one specific application of this feature.
Gotta love ssh...
Maan
There is a free solution included with almost every X server -- lbx. If you want, you can even use lbx and tunnel it through ssh, although that doesn't improve things TOO much, as you add latency.
To enable lbx, log in to the remote machine, make sure $DISPLAY is set correctly and execute something like this:Adjust
Make sure that your X server (on your client) has lbx extensions enabled. If you use Hummingbird Exceed, for example, it's not enabled by default.
Regards,
--
*Art
Except that vnc cheats, and uses change tiles from the screen, NOT of each individual window, and definently ignores the way events interact, except at a more basic level. You'll notice this effect when you're seriously lagged. it'll waste time redrawing linearly, instead of letting the applications group events into batches.
:)
That's why vnc tends to emulate an entire desktop. Things that are infront, behind, in focus, or whatever are drawn to a buffer on the remote server, and updates for the buffer are sent, regardless of wether the update is just a redraw of something that had been seen previously, but hidden.
Now, in case you haven't noticed, X operates differently to this, individual applications can mask out the events that they want, and ignore redraws selectively, although, quite often, as someone else mentioned, programmers rarely take this into account, and redraw more than they need to.
A caching proxy for X will eliminate redraws that AREN'T different, and potentially, recall changes that are the same as they were some previous time. If the proxy understands the X protocol, you can work at the window/event level, not at the screen level, and keep within the normal X paradigm.
Not only that, but windows can still only select the events they care about, and the client side will react accordingly, as you want them to, as you GET with Citrix, where you can run an individual app without a full login shell, with the added bonus of lower bandwidth usage.
Bring it on, especially if it maintains a progressively decaying backbuffer it can use to recall chunks.
ashridah
This explanation is a bit vague, enough to be somewhat inaccurate. If you execute ssh from the Terminal in OS X, X forwarding will not work no matter what you do. You have to run Apple's X11 application, then run an Xterm, then do 'ssh -X wherever'. That is how it is if you are just using the X11 implementation Apple provided you with, not if you installed it yourself. Dunno about the latter situation.
I do it this way all the time, very useful.
From the abstract of the paper submitted for LinuxKongress:
[quote]
The NX protocol is based on a modified X protocol, but vaporizing the many X round-trips down to nearly zero.
To give a few figures:
* a Mozilla start-up alone produces nearly 6.000 round-trips and needs more than 7 minutes to complete over a 9.600 baud modem connection. With the help of NX, the round-trips are boiled down to a few dozen, and a startup may only take 20 seconds over the same modem link!
* a full-screen KDE session transfers 4.1 MByte of data over the wire, if it is run over a vanilla remote X connection. Run it over NX, and the second startup data transfer volume is down to 35 kByte only! You can run KDE sessions over a 9.600 baud modem link and have a responsiveness which is better than TightVNC over a crosslink cable hooking together two boxes only 1 yard apart.
* overall compression/speed gain is 70:1 (on average, across various applications), but can easily achieve 200:1 and more for some applications, like Web browsing.
[/unquote]
s##### start quote ######
NX has a few more goodies built-in:
- ...to connect to Windows Terminal Servers or Windows XP
Professional boxes, using the RDP protocol,
- ...and also to connect to VNC servers, using the
RFB protocol.
In these cases the remote NX proxy uses additional "agents" which speak the RDP or RFB protocols to the remote "foreign" servers. The NX agents translate these other protocols to X primitives, hand them to the remote NX proxy which transfers them down to the local NX client (applying, of course, its built-in compression and caching techniques). NX keeps bitmap updates in their foreign format and translates them into X bitmaps only at X server side, offering, thus, no penalties compared to the client speaking the native protocol. The NX encoding and compression of the resulting X protocol (using its usual algorithms) offer compression ratios ranging between 4:1 and 10:1 in respect to the native RDP or RFB protocol. NX derives its capabilites regarding these foreign protocols from "rdesktop" and "TightVNC" at the remote end, but uses an NX connection between the local and remote proxy.NX is the starting point for a new understanding of network desktop computing. It makes it possible to connect to your own Desktop, running your own application, using your own data from anywhere in the world even over slow connections like GSM-modems. Not too far from now, in the near future we will "NX-connect" on a peer-to-peer basis to remote applications that run on Linux, Mac OS X, Solaris and Windows application servers somewhere in the world, but are displayed at our local PDA. NX may soon define an X-based web, just like HTTP defined a HTML-based WWW.
e###### end quote ######Specifically, take a look at the "-g" option. Using the "-g" option allows other hosts to connect through your forwarded port. However, it only works with the "-L" option, and not the "-R" option.
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.