Wouldn’t it be great if you could connect to the Internet with any computer and view and operate a single desktop? There’s a product called Virtual Network Computer (VNC) that allows you to do just that; from anywhere on the Internet, you can control a Mac desktop. The software is cross platform (it works on UNIX and Windows, too), but its most attractive feature is its price: free. Yes, it’s open source, and it runs under the GNU license. You can obtain a free copy from the VNC Web site.

Basically, VNC consists of a remote display system that allows you to view a computing desktop environment from any machine, from anywhere on the Internet, and from a wide variety of machine architectures. Furthermore, VNC allows you to access the same desktop from a wide variety of platforms.
In January 1999, AT&T acquired the Olivetti Research Laboratory, which was founded 12 years earlier and which developed VNC. The result was AT&T Laboratories Cambridge. Of course, AT&T also took over VNC development.
Any difference?
What makes VNC different from other systems? For the simplest mode of operation, you could achieve a similar effect by installing an X server on a target PC. The important factors that distinguish VNC from other remote display systems, such as X, are:

  • ·        No state is stored at the viewer. You can leave your desk, go to another machine, reconnect to your desktop from there and finish the sentence you were typing. Even the cursor will be in the same place. With an X server on a PC, if the PC crashes or is restarted, all the remote applications will die. With VNC, they keep running.
  • ·        It’s small in size and fairly simple in execution.
  • ·        It’s platform independent. A desktop that runs on a Linux machine can be displayed on a PC or a Solaris machine. Also, the simplicity of the protocol makes it easy to port to new platforms. There is a Java viewer, which will run in any Java-capable browser. There is also a Windows NT server, which allows you to view the desktop of a remote NT machine on any of the supported platforms with exactly the same viewer. (The NT server is not multi-user.) Other people have ported VNC to a wide variety of other platforms.
  • ·        It’s sharable. One desktop can be displayed and used by several viewers at once.

VNC consists of two types of software components: a server, which generates a display, and the viewer, which actually draws the display on your screen. The server and the viewer may be on different machines and on different architectures. The protocol that connects the server and viewer is simple, open, and platform independent. For instance, if you’re using a Mac, you can access a Windows desktop (as shown in Figure A) or a UNIX system (as shown in Figure B). Since no state is stored at the viewer, breaking the viewer’s connection to the server and then reconnecting won’t result in any loss of data. Since you can reconnect from somewhere else, you have mobility.

Figure A
With VNC, a Mac viewer can access a Windows machine.

Figure B
You also can use a Mac to access a UNIX system.

To get started, you need to run a server and connect to it with a viewer. The current VNC software requires a TCP/IP connection between the server and the viewer, though there’s no reason why the software couldn’t be modified to use RS232 or Firewire. For now, you’ll need to know the name or the IP address of the server machine.

The technology behind VNC is a simple protocol for remote accesses to GUIs. Since the protocol works at the high frame buffer level, it can be implemented in multiple operating systems and over any reliable transport mechanism. T. Richardson and K. Wood wrote a paper on this “RFB” protocol in 1998. They did a good job of explaining the protocol, and I’ve gathered some of the following information from their paper.

The remote endpoint where the user sits (the display, keyboard, and/or pointer) is called the RFB client. The endpoint where changes to the frame buffer originate (the windowing system and applications) is known as the RFB server. The RFB protocol was designed in such a way that it purposely makes very few requirements of the client.

The display side of the protocol is focused on a single graphics primitive: place a rectangle of pixel data at a given X,Y position. (Different encodings for the pixel data give a large degree of flexibility in trading off various parameters, such as network bandwidth, client drawing speed, and server processing speed.) A sequence of these rectangles forms a frame buffer update. An update represents a change from one valid frame buffer state to another.

The update protocol is demand-driven by the client. In other words, an update is sent from the server to the client in response to an explicit request from the client. This design gives the protocol an adaptive quality. The slower the client and the network are, the lower the rate of updates becomes. With typical applications, changes to the same area of the frame buffer tend to happen shortly after one another. With a slow client and/or network, you can ignore transient states of the frame buffer. The results are less network traffic and less drawing for the client.

Pixel format refers to the representation of individual colors by pixel values. The most common pixel formats are 24-bit or 16-bit “true color” (where bit-fields within the pixel value translate directly to red, green, and blue intensities) and 8-bit “color map” (where you can use an arbitrary mapping to translate from pixel values to the RGB intensities). Encoding refers to the manner in which a rectangle of pixel data will be sent on the wire. In practice, VNC normally uses only the hextile and copy rectangle encodings because they provide the best compression for typical desktops. Other possible encodings include JPEG (for still images) and MPEG (for the efficient transmission of moving images).

The copy rectangle encoding is a very simple and efficient encoding that can be used when the client already has the same pixel data elsewhere in its frame buffer. The encoding on the wire consists of an X,Y coordinate. It gives a position in the frame buffer from which the client can copy the rectangle of pixel data.

In hextile encoding, rectangles are split up into 16×16 tiles. This division allows the dimensions of the sub-rectangles to be specified in 4 bits each—16 bits in total. Splitting the original rectangle into tiles is done in a predetermined way. The position and size of each tile don’t have to be specified; the encoded contents of the tiles simply follow each other in the predetermined order. The ordering of tiles starts at the top left-hand corner and follows a left-to-right, top-to-bottom pattern.

Stages of the protocol
There are two stages to the protocol: an initial handshaking phase and the normal protocol interaction. The initial handshaking consists of Protocol Version, Authentication, Client Initialization and Server Initialization messages.

Then, the protocol proceeds to the normal interaction stage. At this point, the client can send whatever messages it wants to send, and it can receive messages from the server. All these messages begin with a message-type byte, followed by any message-specific data. The protocol seems robust and flexible, and it survived the test of implementation on various platforms.

In a system that accommodates almost any other type of machine, VNC allows you to manipulate networked Macs remotely. (This interoperability alone would cause me to recommend VNC.) The open source behind VNC allows you to customize any situation. VNC may be the general answer to remote administration that you’ve been looking for. What it lacks in automation (even though execution of AppleScript macros is possible), it makes up for in flexibility. VNC is a good solution to many support problems, and network administrators should consider using it.

Larry Loeb has 20 years of computer journalism experience. He was Consulting Editor at the late, lamented BYTE magazine, he launched WebWeek, he ran the online Macintosh section of BIX (the BYTE Information eXchange), and he wrote numerous articles for many major computer magazines. Recently, he wrote a book on Secure Electronic Transactions, the protocol endorsed by MasterCard and Visa that allows merchants, cardholders, and banks to work together over the Internet. For banter, tips, and general screaming, send Larry an e-mail .

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.