Slashdot Mirror

...try TightVNC. It's a new compression technology added to VNC. It's availble from tightvnc.com. I have found that it is more than usable over a 56k connection even if you are using the java applet in Netscape. The patches are GPLed, just like VNC so there are no unneeded restrictions on using it. Setting your bitrate is a different issue. If you are going to have people accessing via the Java applet, use a 8bit depth. Java can only handle 8bit, and dithering takes forever. If you are going to use the standalone clients (available for all major OSes), then use a depth of 16bit or 24bit. The dithering in the standalong clients is much faster than it is in Java.
If you need it, I also have a patch for VNC that only allows one session and then kills the server. It will even run a script on exit if desired. Drop me an email if you would like a copy. I would link to a page for it, but I heven't tested it in a high-load production setting yet.

I was surprised no one had mentioned TightVNC, yet.

It is supposed to be anywhere between 5 and 75% thinner than even plain zlib compression on a VNC stream.

The original goal appears (to me) to be usability over a dial-up. There are unix as well as win32 variants.

Hope that helps, good luck!

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

Go to http://www.tightvnc.com. They're doing some clever things to make bandwidth MUCH less of an issue. (Including lossy jpeg sessions if desired.)

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.