Low-Bandwidth X

pinzari self-promotes with this: "What about running a full-featured X desktop on your Yopy? Or having a virtual Linux machine, running at your ISP site, being accessed by a TV or PS2? I know Slashdot has treated this more then once and I remember a really interesting thread a few months ago. I think that most of the reasons why nobody has taken this seriously is because nobody thought it was actually possible. Medialogic has just released MS1 of mlview-dxpc. It's a deep rework of the old DXPC which can really be used to run remote X desktops over the Internet, the way Citrix, Microsoft and SCO aim to do using proprietary protocols like RDP and ICA. mlview-dxpc is very preliminary but, in our opinion, it looks very promising. After all this hype about .NET and Application Service Providers, I can't forget X was born exactly for this purpose."

Comments

Re:How useful

[Jeremy Erwin]

As a graduate student, I occasionally need to run xmaple, or matlab remotely-- but only have a 56k modem. (Yes, I do have local copies of the programs, but sometimes I need to test if my files are compatible with my school's versions.) Low Bandwidth X, while not a panacea, does allow me to run some of these programs.

VNC

[perlyking]

X is good, low bandwidth would be better (and judging by what the site says it is better) but I can't help thinking VNC is actually more useful because its only a couple hundred k of program and runs on platforms as diverse as Linux, beos and windows CE (amongst others). Of course YMMV

Re:VNC

[Ed Avis]

Bandwidth isn't the problem, it's *latency*.

Try running XEmacs over a 28.8Kb/s modem link. You'll see the 'send' light flash, then the 'receive' light, then 'send' again, and so on for several minutes. This indicates to me that a lengthy dialogue is happening between the X server on my machine and XEmacs running remotely; and that each side can only say one thing, then wait for an answer.

Most likely XEmacs is asking about all the fonts available and their sizes, or something like that. Maybe it is querying X properties one by one. But anyway, it would be a lot quicker if the X server could just send a single, highly compressed lump of information containing almost everything XEmacs (or any other X client) needs to know. Alternatively, make the communication more asynchronous so that X clients can send several requests at once, without waiting for an answer between each one. Going backwards and forwards across a modem link usually takes about a quarter of a second (for me) - do you want that sort of delay for each of a hundred messages?

VNC (even with compression) is a bandwidth hog compared to X, but it's not so much of a 'latency hog'. Running XEmacs over VNC, it starts much quicker, because the X server (Xvnc) and X client (XEmacs) are on the same machine. The communication that goes over the high-latency modem link does not consist of lots of small requests, (it's just raw pixel data) so the application's response time is a lot better. (At least when starting; if you wait several minutes for XEmacs to start with X-over-modem, it's just about usable once it's running.)

The irony is that compression, which is supposed to make the link effectively faster, actually increases the latency for sending short messages. Of course special compression designed for the X protocol will be designed to minimize the effect on latency.

Re:VNC

[bencc99]

the problem with VNC is that it requires *huge* amounts of bandwidth - it's sluggish over 10 meg lan, and certainly isn't manageable over dialup. X does work nicely over some other platforms - eXceed under windows being a good example.

I think the real issue is that X isn't well designed for low bandwidth use - try something like MS (ick, I know) terminal services, and it's quite useable over 128k isdn, or even over 56k if neccesary. It can be done - it just needs a more efficient use of bandwidth than X currently does.

Still no support for resumable desktops

[ideut]

When I first saw this article, my first thought was that The Thing I Had Been Waiting For had arrived. I thought that we were going to get resumable X sessions.

Resumable X sessions would absolutely rock. There is always a lot of setting up to do when one starts an X session - I don't care how much effort you put into .xinitrc or how intelligent your desktop environment's session management is - there's always lengthy initialisation for my X sessions. Resumable X sessions, combined with a low bandwidth X proxy, would allow me to:

1. Use my same desktop from anywhere in the house (at the moment that's three machines with decent displays)
2. Access my home's desktop from the computer laboratory in town during the day time.
3. Display applications running on various shell accounts across the internet at home and not have to start over when my DHCP IP address changes.

   At the moment I can (and do) use VNC for (1) because I have a fast home LAN. But even tight VNC is too much of a bandwidth hog for (2) or (3).

   Hell, if resumable X displays existed I would probably rent a colocated box on the net's backbone, then just use thin clients (read: sleek X servers) to access my desktop from wherever I happened to be in the world.

   Does anyone have any thoughts on the architecture of the X 'proxy' that needs to be invented? It would have to be a full-fledged X server, and would have to maintain state for any clients which were displayed on it. It would also have to be an X client, capable of displaying itself on a remote computer, but capable of "detaching" from the display and "re-attaching" to another one (that's why it needs to maintain all the state of any clients which are displaying on it.. )

   Colour depths would be a nightmare, as they always are with X.

   Perhaps extending VNC so that "X protocol" is one of the encoding options for communication between VNC server and VNC viewer would be a place to start (though I'm completely ignorant of how easy it would be to graft stuff like this on to VNC).

   I'd be interested to hear what others have to think on the matter.

Re:Still no support for resumable desktops

[garrettl]

It already exists, and has existed for a number of years now... (since 1995)

It is called "xmove", and is available from ftp://ftp.cs.columbia.edu/pub/xmove/

If you're running Debian, then it's only an apt-get away.

If running Red Hat or any other RPM-based distribution, there is an i386 and src RPM available on the 'Net as well.

In addition, I suggest that you try out x2x. Think "Xinerama" across multiple desktops over the network. It's kind of like that. With the combination of x2x and xmove, you can actually move the displays of X applications across machines, and control all of the boxes from one control point. Good stuff. (:

Re:Why remote?

[cyberdonny]

A couple more:

• Access to legacy apps which do not yet exist on your chosen desktop platform?
• App needs to run on remote computer, because it controls hardware attached to that computer. Granted, today you could use a small webserver on the computer where the hardware sits, and use HTTP for client/server communication, but what if the hardware is closed and legacy, and only ships with an closed-source X app running on SCO?

TightVNC

[tessellation]

anyone interested in using remote desktops over IP networks ought to take a look at TightVNC, which implements lossy JPEG compression (finally). It's about 70% better than VNC and about 90% better than PCAnywhere 9 from my personal trials. To give you some idea of the improvement, you can now use TightVNC over ISDN from Japan with good responsiveness, compared to waiting two minutes for a screen refresh with plain VNC.

queing is implemented in X but...

[a_hofmann]

Actually newer generations of X servers queue protocol messages to a batch of many requests/replies to address this problem. The problem is, in real world applications this doesn't work out very well because of the way Xlib programs are written.

The low level implementation of X programs requires a linear flow of

REQUEST info A, SET property B, REQUEST info C, REQUEST info D, SET property E

, and so on...

Because there is no way for client nor server to understand which information/property depends on any preceding, the protocol messages have to be processed one after the other.

In cases like requests to set/request a large set of similar properties (e.g. color information), queuing takes place and messages are sent containing a whole batch of single events, but this doesn't happen often in real world applications, thus not noticably increasing performance.

The X protocol was not designed for an asynchronous message flow.

TightVNC vs X

[const_k]

I am developing TightVNC software which features a number of efficient bandwidth optimizations for well-known VNC software suite, and I'd like to share my opinion and experience on low-bandwidth remote desktop solutions. I think TightVNC and future versions of TridiaVNC may be a better alternatives as compared to X in all its flavours (with LBX, DXPC etc.) and I'll try to explain why in the text below. In short, I don't feel much pain using TightVNC over 33.6 Kbps dial-up connection.

Speaking of X and TightVNC, each choice has its specific benefits and drawbacks. First, let's look at strong sides of TightVNC (many points are applicable to the standard VNC, except for the bandwidth usage):

1. TightVNC requires minimum amount of code at the client (user's) side. The client does not require installation and it's size is about 200..300 KBytes. Moreover, you can access any remote system when no native client available: your remote desktop may be accessed from any Java-enabled Web browser, just type the hostname and port number of TightVNC's internal httpd.
2. TightVNC is truly multi-platform in its design and complexity level. Developing a new client is very simple task, the protocol is very simple. There are clients for X and Win32 environments and platform-neutral Java client (only 30 KB of compressed byte code!).
3. TightVNC is better suited for operation in network environment in general. For example, it just skips screen areas that are obsoleted at the moment when a client asks for screen update.
4. TightVNC does not deal with fonts on the client side: therefore it does not depend on font sets on the client system and does not require configuring font servers etc.
5. Compression level in Tight encoder is configurable on the client side and there is a possibility to enable lossy JPEG compression with adjustable image quality. If you don't care about every pixel appearence but just want to get work done, JPEG compression with low image quality level will efficiently use limited bandwidth even on most complex desktop contents.

From my real-life experience, TightVNC session is usually more bandwidth-friendly as compared to X with SSH compression, but X and VNC are very different in their architectures, and there are situations where X is more efficient. And it's not always simple to compare X and VNC.

The main problem of X is its complexity. X was intended to be too flexible and universal by design, but this also means that underlying techniques and protocols are extremely complicated. I often imagine X died under the pressing of it's own complexity. Now about weakness points of the TightVNC:

1. TightVNC always exports the whole screen when X deals with separate windows.
2. VNC was not designed to be secure. There is a number of serious security flaws. X is not perfect in this sense, too, but it's a bit better.
3. Most impressive TightVNC features (local cursor support, JPEG compression, Tight Encoder 1.2) are still in the development phase. While Unix code and Java viewer are ready, Win32 version is not -- there are known bugs at this moment (to be solved in a week).
4. There are problems with internationalization in TightVNC.

Maybe I've forgotten to say something above, but now it's too late and I have to go now.

--
With Best Wishes,
Constantin

Free X server for Win32 from RedHat

[johnnyb]

RedHat is doing a Win32 port of X. See the scoop at

http://sources.redhat.com/win32-x11/

and

http://sources.redhat.com/cygwin/xfree/

These actually may be the same project. Says it runs on Windows 95, Windows 98, and Windows NT. I expect it would run on Windows 2000 as well.

Grunge dropping New Jack through a press table

[Graymalkin]

Running X over a low bandwidth or high latency connection is asking for trouble. You might get a static desktop up and runing fine on a Yopy or some little toy but if you run something even mildly intensive on the graphics (say Gimp for instance) you're not going to be very happy with performance. Not only does it have to send an updated screen for every filter or change to make to an image you also have little things like the animated border around a selection. I used to connection to the SPARC stations at my friend's school over the internet and it was a drag even with a cable modem. Most recent X apps are not designed with bandwidth skimping in mind, they're designed like Windows and Apple apps. You get spoiled when you start making apps people use only on their local desktops whereas app engineers 15 years ago would go to the greatest pains to skimp on bandwidth as no one ran X on a desktop machine. X has VERY little to do with .NET or low level RPC frameworks. X provides communication between top level components over the network (such as the GUI) whereas CORBA, COM+, ect. provide network access to lower level components. .NET and any framework like is much better suited for accessing remote program components. You can use SOAP to communicate with an Apache or IIS module through HTTP transfering only a couple objects as XML documents where X is transfering lots of widget descriptors and frame images.

DXPC, lbxproxy and SSH compression

[SWroclawski]

There are several programs for this.

lbxproxy works with X. Part of it actually comes with XFree86.

DXPC is an oldie but goodie. It requires you to use it on both server and client end though.

And good old SSH compression is usually good enough. Turn on X forwarding, turn up the compressiona and usually you're good to go.

I haven't found VNC to be very good for bandwidth, but you might want to try a VNC compressor like this.

- Serge Wroclawski

Read the link

[Arker]

Geez, read the link before you post, people. This isn't a lightweight desktop, it's a module for compression X protocol traffic. That's the big problem with running remote X sessions - they eat bandwidth like nothing else.

Fortunately it's also quite compressible. By optimising compression for the protocol, they're claiming to average 60:1 compression, making it possible to run a full-on X session on a 64k link... yummy.

"That old saw about the early bird just goes to show that the worm should have stayed in bed."

LBX is useble at 128kbit/s

[Baki]

From my work I can reach my home at 64kbit/s. First I tried X, but it ran too slow. Then VNC: too slow either, it seems to send the whole screen as a huge (compressed) bitmap.

LBX though is somewhat usable at 64, and really usable at 128kbit/s. I don't see how VNC could be a match for LBX. Also VNC somehow looks very ugly (probably a fonts problem).

X in itself is well designed for low bandwidth use, since it doesn't send the screen (or parts thereof) as bitmaps, but only sends graphics primitives (draw line, draw rect etc). LBX adds compression of events, omision of non-essential events and also (if you want) stream compression (I don't use it since I run LBX over a compressed SSH stream).