Virtual Network Computing 3.3.3r7

After rounding up remote control products in the May 2000 issue, Windows 2000 Magazine received many letters asking us to take a look at Virtual Network Computing (VNC) from AT&T Research. This product caught me by surprise. VNC isn't the most polished or full-featured remote control product available for Windows, but it's pretty good and has some compelling advantages. For example, VNC is free and available under the GNU General Public License (GPL), so the source code is fully available and you can make derivative works for your own purposes. (GNU is a recursive acronym that stands for "GNU's Not UNIX." It's one of the original, free, UNIX-compatible OSs. For more information, see The GNU Project by Richard Stallman.) However, the commercial competition doesn't need to worry; VNC squarely targets expert users and has more than its share of problems.

I tested version 3.3.3r7 of the Windows product. VNC is also available for Mac and many versions of UNIX. The authors expect that the product's most common use will be to control a remote UNIX server from a Windows client. In this situation, VNC and its underlying remote framebuffer (RFB) protocol should outperform the X protocol (a GUI-based protocol for UNIX systems), especially on a slow link because X is very inefficient.

You can use VNC as a general-purpose remote control product, but not if you need hand-holding. VNC's documentation is entirely online, and it's good as far as it goes. But the documentation is sparse, and the program has no Help system. Open-source advocates will say that VNC is more thoroughly documented than its competitors because you have its full source code. They're right—if you're fluent in C++. The open-source world also influenced VNC's support approach. You have no phone numbers or email addresses; instead, you get an Internet mailing list and an Internet Relay Chat (IRC) channel, both of which you can access from the VNC Web site.

Installation
To test VNC, I installed the software on identical client and server systems consisting of a 500MHz Pentium III with 256MB of RAM, ATI Rage Pro AGP graphics card, and a 100Mb LAN card running Windows NT 4.0 Service Pack 5 (SP5). VNC has two parts: the viewer, which you run on the client system, and the server, which you run on the system you control. The viewer is small (172KB), simple, and requires no installation. I simply downloaded the executable file and ran it; then, I could select a server to control by name or IP address (VNC supports only IP, not direct dial-up, NetBEUI, or IPX/SPX). Figure 1 shows the VNC viewer window, the viewer program running on the client, and the Windows session running on the server.

The server program requires a standard Windows installation. The documentation strongly recommends that, on NT, you run the program as a service, which you set up separately by running Start, Programs, VNC, Administrative Tools, Install WinVNC Service. (Oddly, none of the NT remote control programs I've tested sets itself up to operate as a service by default.)

Configuration
VNC performs configuration in several places and could use some improvement. You open the Current User Properties dialog box through the Tray icon, you open the Connection Options dialog box from the System menu, and the documentation doesn't explain many of these settings. For example, the Preferred Encoding section of the Connection Options dialog box allows: Hextile (the default) where rectangles, such as windows and dialog boxes, are divided into 16x16 pixel tiles; compact Rise and Run Length (CoRRE) where rectangles are set no larger than 255x255 pixels; Rise and Run Length (RRE), which uses traditional run-length encoding to convert the rectangle into an easily rendered format; and Raw, which uses one bit per pixel. I can tell from the source code that VNC sets different formats for rectangular data in its protocol, but I had to go to a separate protocol definition document to find the formats. Later, I found that the documentation for the UNIX version explains this topic better.

What's really cool about configuring VNC for Windows is that the documentation contains numerous relevant registry settings. Sometimes, such as when it says how to make settings user-specific or systemwide, I wish that AT&T Research would just implement a user interface. But this documentation lets you create .reg files that you can distribute to users to customize settings. You can also use the server registry to set ranges of IP addresses that might connect to the server.

The huge variety of VNC's command-line options is well documented. I counted 23 possible command-line options for the Windows version of the viewer, although some of them relate only to UNIX servers or an internal version of VNC that AT&T Labs Cambridge doesn't release. For example, you can use the -fullscreen parameter to run the session in full-screen mode, with only the remote server session displaying. You can use the –viewonly parameter to run the session in view-only mode to observe what happens on the server side without sending mouse or keystroke events to it. Support personnel might find this capability helpful.

VNC requires that a client enter a password before taking control because you can break into a running Windows session with VNC. A documented registry setting can override this policy, but it's a good one. However, if you connect to a server while another connection exists, you will disconnect the other client. It would be a good idea for AT&T Research to give the user of the existing connection some time (e.g., 10 seconds) to stop the new client from connecting. The fact that you can move from client to client connecting to the same server is intentional because it lets you, for example, go from the office to home and work on the same server. However, this capability can compromise the security of a connection.

When you connect to the server, you have effectively two cursors—local and remote. Among the programs I've tested, only VNC displays both: The local cursor is a dot, and the remote cursor is an arrow (while the mouse is in the VNC window). This feature can be useful because the cursors' positions can differ at any point in time. When you click the mouse button, it sends the local mouse position to the event queue. You can disable this feature.

Pluses & Minuses
VNC's performance wasn't great. VNC is reasonably fast, but considering my client and server hardware, I expected better. However, when I switched from 32-bit to 16-bit display color depth, as the documentation strongly recommends, I saw a big jump in performance.

I saw a lot of visual artifacts in the display, and scrolling in most applications caused the image to tear, as Figure 2 shows. By changing the polling settings in the Current User Properties window to Poll Full Screen, the program worked properly, but performance took a noticeable hit. With this setting, the WinVNC service consumed between 16 percent and 30 percent of CPU cycles, even when the system was idle. Loading an application guaranteed large stretches at 100 percent usage. Most other remote control programs don't visibly slow the system as much as VNC.

VNC has no file transfer function, which is a standard feature in most other remote control programs. The documentation makes the valid point that if you have a TCP/IP connection to the server, which you need for VNC, you have many reasonable alternatives for file transfer. Even so, from my experience using remote control to administer remote NT Web servers, I know that an integrated file transfer feature can be a huge convenience. Another problem VNC has, compared to most other remote control products, is that its cross-platform requirements require it to deal with inconsistencies in file system rules between the Mac, Windows, UNIX, and some of the more obscure platforms.

Both client and server require NT 4.0 SP3 or higher. I also tested quickly on Win2K SP1 and saw no new problems. If you need to control a Win2K Professional system, VNC might be a good option. But to control a Win2K Server system, the built-in Terminal Services in Remote Administration mode are a better option.

VNC has a Java applet-based viewer that I liked. In addition, the VNC server is an HTTP server, so I can connect to it from any Java-enabled browser, including Microsoft Internet Explorer (IE), by addressing http://server_name_or_address:5800/. This version doesn't have some of the Windows viewer's features, but it's very convenient and worked better for me than other products' ActiveX solutions. I found one big problem in VNC, however; using the button that sends a Ctrl-Alt-Del to the server disconnected the session from the Java client every time.

Even though I found several problems, I see a lot to like about VNC. First, you can't beat the price. If you have a mixed environment, including Linux and Macs, VNC is a good, inexpensive way to control them from each other. Finally, having the source code lets you find the problems and potentially fix anything you don't like about the program. If only NT experts with a high tolerance for registry tweaking will use the program and they're willing to get support from a mailing list, VNC is definitely worth trying.