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."
Hmmmmmmmmm......yup, they're definitely prepared to be a
1. No sig. 2. ???? 3. Profit!!!
just how useful will mozilla be to me on my cell phone with its miniscule display, or any other full blown regular GUI based PC app for that matter?
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
(Sorry, but I'm not able to read the PDF right now, and there doesn't appear to be a whole lot of technical info on the web site.)
So can anyone address how this new product is any different or better than Low Bandwith X? LBX is also a proxy server that caches a lot of information local to the application cut down on traffic across the slow link to the actual X server. I've used it to run programs like XEmacs and XTerm across 56K links and it works very well. It's less useful at graphics-intensive programs like Gimp.
I thought the only one was /usr/bin/fortune or have I missed something??
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.
What would be cool also would be if you could use X over a single connection from your local machine to another, so you can use it from an rfc1918 address behind NAT to the "server", without having to set up tunnelling.
Citrix is pretty fast (I use the Linux Citrix client on an OpenBSD box to work on a machine halfway across the country) but it caches a huge amount of data locally. Of course that's the tradeoff for the speed you see. If speed isn't that big an issue stick to TightVNC, the price is right :)
Trolling is a art,
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
Network transparancy is one of the shortcomings of X11 -- I mean, who would ever use this? They ought to figure out some directfb stuff for the cell phone or something. /typical x-hater statement
This is cool -- and one of the reasons why X is cool. While it's aimed at mobile devices, it'll breathe new life into old hardware, too. Like my SS10, for instance -- it's too slow to run much anything other than NetBSD and an X server. But it runs remote apps fine. It could even make my old Mac Quadra useful as a basic X console.
Just what X was made for I thought.
First I tried straight X (over ssh -X -C of course). This is on a 256k upstream DSL link.
The performance was pants. Really bad. At first I thought I must be doing something wrong. To be honest, Gimp wasn't too bad, but a Gnome 2 application like Xchat2 was really slow. Menus would take an age to display.
I tried looking around for a low bandwidth solution, but couldn't find any free ones.
I've ended up using VNC over SSH. It's much better than straight X. Plus it's got the added advantage that I can just leave the application running, and connect to it from anywhere.
With X, there is no easy way (xmove was impractical) to leave an application running, and move it between desktops.
-- Hulver's site
The mobile phone screen angle is a red herring. The really great thing about this is that it massively reduces the bandwidth required for running X over the network and it also reduces latency. The issue is that X consumes a lot of bandwidth. In some cases, if the bandwidth is available, X will use up to 10 Mbps to display a remote application screen. This is excessive and limits the use of X. Running X through ssh with compression enabled helps tremendously but can still consume 220Kbps. VNC offers similar 220Kbps or less performance to X through ssh but has much higher latencey so, it's not perfect either.
This new NX proxy is claiming 9.6Kbps X applications. Even if it doesn't come close to delivering that and is closer to 28Kbps or even 40Kbps it is still a massive improvement over X and ssh or even VNC and it now falls in line with the Citrix ICA protocol. It also apparently adds some of the Citrix features that X was missing but, the reduction in bandwidth alone is a tremendous improvement. You don't have to use it on a mobile phone and chances are I never will.
Yes it is. In fact, X is liked by so many because of its network transparency.
However, the amount of data that a typical "rich" X client sends (e.g., mozilla) is huge. Many X clients are not optimized in terms of the amount of display information they output (that is, they output a lot of stuff that could probably be optimized away). For many developers, this is within reason since they figure that most of the time the xserver and xclient will be on the same machine (e.g., running mozilla on my box to display on my monitor).
This handy piece of proxy software put out by NX claims to be able to cache a lot of the data that X clients send, thereby reducing the amount of data actually transmitted. This will allow "rich" applications which send a lot of data to be run over slower connections with an apparenet reduce in lag time.
/<en
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
One simple answer: ssh.
you've got that right...but how does one ssh to their phone?
We're like rats, in some experiment! -- George Costanza
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.
Always the problem with these things. ssh display forwarding and lbxproxy can both reduce the bandwidth used by X11 but both increase the latency, sometimes to unacceptable levels.
On the corporate LAN we have 100Mbit switched and haven't noticed bandwidth being a problem. We have however noticed that both lbxproxy and ssh require more CPU in order to perform compression and buffering which *can* be a problem on a shared server if the number of concurrent sessions it can support drops by 20%.
I guess if you want X to your phone then it could be an issue, but that's a fairly niche market.
Government of the people, by corporate executives, for corporate profits.
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.
Basically, data over GSM is a bad idea. The max speed is 9600 kbit/s. There are other alternatives, such as HSCSD (High Speed Circuit Switched Data) which will provide 56.6kbit/s, and GPRS (General packet Radio Service) which will give up to 384kbit/s (if using EDGE). Then, we have the 3G standards, CDMA2000 and WCDMA, with up to 2Mbit/s (close to the base station, and only if you're almost alone in the cell...) While the 3G isn't much available, GPRS is. Why you'd like to use the GSM for data is beyond me.
Did I read this correctly? A project aiming to allow rich interfaces remotely is going to use a crippling web interface for administration? *boggle* I hope by "including" they mean "it'll be there, but you don't have to use it and we'll have something a tad more functional".
Note to self: pasty-skinned programmers ought not stand in the Mojave desert for multiple hours. -- John Carmack
Another product that's been around for a while and works pretty good is Differential X Protocol Compressor. How does this new product differ?
This is great to hear. Up till now, even though X has had remote display abilities built-in, it has not been at all practical to replace something like ICA or even RDP. The next step though is to get thin client manufacturers (maybe neoware's linux-based models?) to support this protocol natively. The article doesn't mention how large the libraries required for NX are, but hopefully it is something that could be added to existing thin clients.
Along with that step, it would be great to see "shadowing" support, which has been one of the killer support features of Metaframe (and now TS). The neoware devices have built in tightvnc, but it is not quite as good as ICA/RDP shadowing (NX probably wouldn't have been necessary if it was)
-Mark
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.
Not anymore, they don't.
There is no sig, there is only Zuul.
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
The KDE League has been behind this, and every major assassination in the 20th century. They're responsible for the California recalls, although Arnold has put a stop to their fiendish plan to take over Governorship and rename the state to Kalifornia.
They will be targetting Kolorodo next, then the cities of Kleavland, Klearwater, and Koopersville.
They've already got Kansas, Kulpsville, and Kure Beach. Cincinatti will be wiped off the map for its insolence of using a "soft c" sound, then Chicago for the dipthong fiasco.
They need to be stopped! At all costs!
I know nobody likes to talk about p... pr... proprietary applications on Linux, but in reality, commercial applications will an important part of Linux's future if it ever takes hold on the desktop. Could this functionality, delivered to any X application be perceived as a reason NOT to develop commercial applications for linux?
Citrix ICA has a very stringent license-management system, allowing licensed applications to be served remotely only to licensed clients, and only to a limited number at a time. This is important for software publishers... they don't want groups of people to buy 1 license and serve it for all their friends.
Why hasn't Windows implemented functionality like remote X applications? It's not like it would be hard for them, although you know they'd never get it secure. Imagine if ANY windows program could be served to other people indiscriminately. That would kill their licensing scheme. A perfect example of why proprietary software development works against the needs of the consumer. Windows users haven't demanded Windows network transparency because they either don't know it's possible, or think Terminal Services is "OK". (haha, good one). There's a reason why Terminal Services will only work for 1 desktop at a time.
I have a feeling that the network-transparency of X is already a barrier to many commercial applications. Now this proxy server thing is going to make it work better and faster, even with higher latencies/lower bandwidths? Not that it's a real problem, but if you were wanting commercial apps like Adobe, Macromedia, sound editing, video editing, 3d redering, etc. to come to Linux, maybe it'd be worthwhile to think about license protection mechanisms for X applications...
-3Suns
~~~~
The Revolution will be Slashdotted
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.
There is a reason they didn't include it.. it was NOT NEEDED for what they were doing. They needed platform independent remote view/control. Nothing more, nothing less.
*ALL* modern operating systems have native file transfer mechanisms.. there is no need to bloat out something like VNC by re-inventing the wheel and shoving it in there..
Integrated encryption.. would be useful, unfortunately.. ( shouldn't even need to be a consideration, but in today's sick world it is. )
---- Booth was a patriot ----
>>How does this new product differ?
DXPC was a pre-decessor to NX. NX developers used to work on DXPC. They have now create something that is 100x better and more usable than DXPC -- and they are not finished yet with development.
Exciting features are on the way: one ins session detaching and re-attaching from a different local host....
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.