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

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. (:

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.

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