Virtual network computing (VNC), a remote access application from AT&T Laboratories Cambridge, is a great tool for remote desktop viewing and manipulation. Its core function is to allow the user to use the VNC client to connect to a host running the VNC server and remotely use the server's desktop. Keyboard and mouse updates are sent to the server, and snapshots of the server's desktop are compressed and sent back to the client via the VNC protocol. A few of VNC's most compelling features are: excellent platform portability, an open-source code base, conservative bandwidth usage and excellent pricing (free!).

For this review I have evaluated VNC primarily in three areas: stability, performance and portability. Below, I also compare VNC to X to illustrate the domain of usefulness for each. For this evaluation I used the following test scenarios:

<il>LAN: Connecting between a K6-2 400 (Linux) and PIII 560 (Linux, Win2k) via 100Mbps Ethernet

<il>Broadband: Connecting between a PIII 650 (Linux, Win2k) and K6-2 400 (Linux) via 768kbps DSL

<il>Modem: Connecting between a P133 (Linux, Win98) and a K6-2 400 (Linux) via 33.6kbps modem

I tested using all machines involved as both server and client under all operating systems installed. Under Linux my test applications were xterm, Netscape 4.7, KDE, StarOffice 5 and the GIMP. Under Windows my test applications were command.com (or cmd.exe when applicable), Internet Explorer 5.5, Microsoft Word 2000 and Adobe Photoshop. Both platforms used unmodified copies of the current versions of VNC, 3.3.3r2/3.3.3r9 (Linux/Windows), both available on the web site. The results were somewhat predictable.

Installing the VNC server on Linux is fairly simple; you can run it out of the build directory if need be. Configuration of the server is achieved by editing the vncserver Perl script to match your system configuration, editing VNC's xstartup script to match your preferred desktop configuration, and running vncpasswd to set a password on the VNC server (it will refuse to run without one, which given the nature of the application is a good thing to do) Note that if you are using the Linux system as a client you don't need to do any more in the way of installation than copying the vncviewer program into a convenient location on your path. There are a number of things you should configure before you start the server, most importantly a password, the startup script, and resolution and color depth. You should also ensure that the default desktop that VNC loads does not use a pixmap as its desktop, as this will degrade performance greatly.

Installing the Windows VNC server is similar to the setup procedure of its Linux counterpart; unzip the installation files, run the installer and you're done. As with the Linux version, if you only want to use the viewer, you can simply copy vncviewer.exe to a convenient location and not install the server. The user interface of the Windows server will be somewhat easier for most people to configure (configuration is available via an icon on the taskbar). The one important limitation that manifests itself on the Windows platform is that connecting to a Windows VNC server connects you to the existing desktop visible on the console, rather than a virtual desktop created for VNC. This is due to the inherently single-user nature of the Windows UI, and there is no simple way to fix this short of running a version of Windows like NT Terminal Server Edition. Overall, though, installing VNC on a Windows system should present little trouble.

My first test used my LAN configuration. Performance on this setup (Linux on a K6-2 to and from Linux and Win2k on a PIII via fast Ethernet at 1024x768 true color) was quite good when going both ways, whether connecting Linux to Linux or using Windows as the client or server (performance in all instances appeared to be identical). While there was a slight but noticeable lag in updating the screen, all of the test applications were quite usable (as one would hope, given the connection over Fast Ethernet). The xterm felt as fast as if it were local, StarOffice loaded and displayed documents flawlessly, Netscape ran reasonably well, and the GIMP was slow but usable. The Windows applications functioned similarly with one exception, as explained at the end of this review. All in all, LAN performance is more than acceptable.

My second test was on the broadband configuration. The parameters of this test (Linux on a K6-2 to and from Linux and Win2k on a PIII via 768k DSL at 1024x768 true color) are both common and, as detailed below, quite sufficient for most applications. The applications reflecting the most common usage patterns—StarOffice and MS Word—both run acceptably over the DSL. Both command-line environments (bash in xterm and cmd.exe) worked fine and the web browsers were reasonably usable. This greatly increases the usefulness of VNC, as many small (and not so small) businesses as well as a fair number of home users rely on DSL or a comparable link for connectivity. The applications that I found not to work acceptably were the GIMP and Photoshop. Both choked the connection while editing, which makes sense considering that a full-screen bitmap photo at 1024x768x24 is more than two megabytes, and editing a photo involves redrawing the screen repeatedly. Other than the photo editing issue, however, I found that VNC was quite usable over the DSL. For accessing most office productivity applications, VNC over broadband performs acceptably.

The third and last test configuration consisted of the aforementioned K6-2 connected to a Pentium 133 via 33.6kbps modem. Due to my experience with the DSL connection, I deemed 1024x768 at true color likely to be too bandwidth-intensive to work well at modem speeds. Because the Pentium machine was a laptop with an 800x600 screen, I opted to use 800x600 at 16-bit color as the screen mode of choice. Before I go into the details of this round of testing, let me give you the one word summary: slow. To preserve one's sanity, I would not recommend spending a lot of time running VNC via modem. That said, basic applications ran without real problems. StarOffice, Word and the two command lines all were usable to a reasonable extent. Anything beyond that involved a great deal of waiting. I attempted to run both Netscape and Internet Explorer and, though both ran, they loaded pages so slowly as to make early builds of Mozilla seem lightning fast in comparison. The bottom line is that, while VNC does function over a modem to a certain extent, I would not recommend using it as anything other than a last-resort backup for your normal means of access to the desired remote computer.

After reading the above, I'm sure many readers are wondering why they should bother with VNC when another excellent remote access tool, the X Window System, is included in some form in nearly all Linux distributions. This is a good question, and the answer is straightforward. In certain scenarios VNC possesses several strong advantages over X, specifically in cross-platform support, security, client-side statelessness and client-side resource usage. The first of these, cross-platform support, is simple. While X servers exist for many platforms, they are often neither free nor any variation of open source.

You may want to make a few modifications to your usage habits to improve your productivity, primarily in the area of scrolling. Because VNC is an abstract protocol and does not link to the underlying graphics system (i.e., at the accelerator level), it sees the screen as only a pixmap and does not follow what X or the Windows GDI is doing. Because of this, you must redraw all changing areas of the screen, even if you are simply scrolling a document. Because of this, I would recommend you become accustomed to scrolling by page instead of by line to minimize the amount of time spent redrawing the screen (once per page rather than once for every line scrolled). Common situations in which this makes a big difference include paging through a spreadsheet or word processing document full of charts and diagrams, scrolling through an image in the GIMP or Photoshop or, if you are so possessed, browsing the Web through VNC. This also becomes an issue in many Windows applications that attempt to use Windows' smooth scrolling feature; because of the way the GDI accelerates this function, VNC cannot track the current screen image properly and will fail to draw the screen correctly. A second workaround to this is to turn off graphics acceleration in the Display Properties control panel under the Troubleshooting tab of the advanced settings screen (accessible via the Advanced button under the Settings tab). While this will greatly slow video performance when working at the Windows machine's console, VNC is far better able to correctly display and refresh the screen with these settings. In a similar vein, having a fast video card—or any video card for that matter—won't help you under Linux. In fact you don't need a display adaptor of any kind on a Linux VNC host because VNC creates its own virtual display.

VNC is one of the more useful programs in existence. That it is being developed by a group devoted to research (AT&T Laboratories Cambridge) and that it is available under the GPL are both good points. VNC is well-suited for applications where remote access to and from diverse platforms is needed, and I would recommend it to anyone looking for a good graphical remote access tool.